signedness in LUI instruction

[theandrew168]

signedness in LUI instruction

[theandrew168]

After digging a bit more, I'm not quite sure how to proceed with this one. In our chat discussion, the examples given for this use case were the common lui + addi combo for loading 32-bit immediate values. Due to the nuances of how RISC-V handles sign extension, I had to introduce a couple modifiers into the syntax in order to make this "work".

For example, it is always recommended (and usually necessary) to utilize the %hi and %lo modifiers when loading 32-bit immediates. They do no harm to values where the signedness causes no issue, but they "fix" values that would end up incorrect due to the sign-extension behavior of addi.

ADDR = 0xffffffff
lui  t0, %hi(ADDR)
addi t0, t0, %lo(ADDR)

An even simpler solution, however, would be to use the li pseudo-instruction. It automatically handles the insertion of proper hi/lo modifiers.

ADDR = 0xffffffff
li t0, ADDR

Are there other use cases outside of this that I'm missing? I'm trying to get a better understanding of the behavior folks will expect as they find this assembler and start tinkering.

[theandrew168]

After discussing this a bit more offline, it isn't a "showstopper". If signed operands accepted values outside of their "documented" range, would devs get confused? Would someone think that the assembler accepted their high, unsigned value when in reality it got flipped negative? One option would be to relax the range constraints for non-decimal numbers (octal or hex). But, the assembler currently has no bookkeeping for how an integer literal came into existence. A bit of extra machinery would be needed to track whether a numeric value came from a decimal, octal, or hex literal.

Unfortunately, this issue is going to remain a "won't fix" for the time being. Perhaps a v2 of the assembler could have the foresight to implement behavioral distinction between the various numeric literal formats.

[theandrew168]

Actually, after digging a bit more into #11, I'm less worried about the "signedness surprise". Especially with 20-bit values. The actual fix for U-type instructions (AUIPC and LUI) was only a couple of lines. There is also some nuance to the immediate value given to C.LUI that I plan to be flexible with, as well.