[Assembler] .byte/.short don't support MOS expression parsing

[asiekierka]

Quoting jroweboy:

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 tables
LoAddress:
.byte label1@mos16lo, label2@mos16lo
HiAddress:
.byte label1@mos16hi, label2@mos16hi
; ca65
LoAddress:
.byte <label1, <label2  ; < and > can be used as shorthand
.lobytes label1, label2 ; alternatively using lobytes
HiAddress:
.byte >label1, >label2
; alternative defining using define
.define AddressTable label1, label2
LoAddress:
.lobytes AddressTable
HiAddress:
.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:
.byte 340@mos16hi ; Does not compile
; ca65 lets you do this though
Whatever:
.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).