You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Making split lo/hi LUTs gets very verbose without </> or .lo/hibytes (Keep in mind that you can't split the address using C/C++ code, so ASM is the only way to make an optimized split lo/hi address table, so this is not a contrived example at all. I suspect this would be fairly common in real code)
; Making a split LUT table; gnu as gets very verbose for larger tablesLoAddress:.byte label1@mos16lo, label2@mos16loHiAddress:.byte label1@mos16hi, label2@mos16hi; ca65LoAddress:.byte <label1, <label2 ; < and > can be used as shorthand.lobytes label1, label2 ; alternatively using lobytesHiAddress:.byte >label1, >label2; alternative defining using define.define AddressTable label1, label2LoAddress:.lobytes AddressTableHiAddress:.hibytes AddressTable
Can't use @mos16lo/hi for freestanding values. This came up when generating value tables (i worked around it by just making the generator code cut the hi/lo byte)
Whatever:.byte340@mos16hi ; Does not compile; ca65 lets you do this thoughWhatever:.byte >340, .hibyte(340)
This issue considers only the fact that .byte <label1, <label2 doesn't work in LLVM-MOS. (Adding support for .lobytes or other constructs can be consdered separately.)
One solution to solve this would be to override .byte, .short, et cetera with our own variants which take MOS expression parsing into account. This is the approach already undertaken by the AVR and MSP430 target backends.
Another solution would be to try and override the expression parser. Quoting @mysterymath :
Yeah, it's arguably a wart that our modifiers don't generally apply to expressions (producing relocs in instructions and appropriate directives, and producing constant evaluation effects otherwise). I'd definitely be supportive of work towards that end, assuming that it doesn't require completely refactoring LLVM's parsing/evalutation interfaces for assembler expressions.
While this would solve the problem more generally, there's at least one known caveat here: WDC syntax (which is what is being implemented as part of #456 ), as well as the ELF specification, distinguishes between modifiers when used on immediates (so lda #imm, but also .byte, .set) versus used on addresses (lda addr, but also .reloc).
The text was updated successfully, but these errors were encountered:
Quoting jroweboy:
This issue considers only the fact that
.byte <label1, <label2
doesn't work in LLVM-MOS. (Adding support for.lobytes
or other constructs can be consdered separately.)One solution to solve this would be to override
.byte
,.short
, et cetera with our own variants which take MOS expression parsing into account. This is the approach already undertaken by the AVR and MSP430 target backends.Another solution would be to try and override the expression parser. Quoting @mysterymath :
While this would solve the problem more generally, there's at least one known caveat here: WDC syntax (which is what is being implemented as part of #456 ), as well as the ELF specification, distinguishes between modifiers when used on immediates (so
lda #imm
, but also.byte
,.set
) versus used on addresses (lda addr
, but also.reloc
).The text was updated successfully, but these errors were encountered: