Unable to use .equ with li pseudo instruction.

[houghtonap]

My environment is using the VS Code extension for venus on Windows 10. I am writing some code and came across an oddity of using .equ with the li pseudo instruction. the code looks like:

         .text
hash:    .globl   hash
         .equ     prime, 0x01000193
         .equ     seed, 0x811C9DC5
         li       a3, prime
         li       a0, seed

This results in the following error in the Venus Terminal:

AssemblerError: test.riscv:36: immediate value out of range: 16777619
li      a3, prime

However, when I remove the .equ and assign the values directly it is successful:

         .text
hash:    .globl   hash
         li       a3, 0x01000193
         li       a0, 0x811C9DC5

Looking at the riscv-asm-manual on github it appears what I'm trying to accomplish is the same as the example in the manual.

[byarbrough]

@houghtonap I'm not familiar with this project, but looks like you are triggering the error in either ImmAbsStoreRelocator or ImmAbsRelocator.

You can prove this because:

.equ     FINE, 2047 # small enough
li       a3, FINE

.equ     ERROR, 2048 # too big
li       a3, ERROR

But you need to look through and see if you can figure out why it's doing that check and if those are the correct values of the check. Sorry, I was just passing by the project, and don't have time!

I think you can close https://github.com/kvakil/venus/issues/29 since this seems to be the correct repository.

[ThaumicMekanism]

Ah I missed this email. Ill take a look later this week to see what is up with that as I cannot answer this off the top of my head and I agree that it looks like a bug with load immediate not correctly splitting up the variable.

[ThaumicMekanism]

Sorry for delaying looking more into this issue. From what I currently see, this is due to the way the pseudo instruction LI is generating the true assembly language instructions. If it is a label, it seems to return just an addi instead of trying to do something more generic to get later resolved. Im looking a bit closer into this to see how hard of a lift it will be to fix this although I cant give a good estimate on that. Specifically this is where we start to get into an invalid state: https://github.com/ThaumicMekanism/venusbackend/blob/18cbc2c409b417eb779abc0668be14aed96aa676/assembler/pseudos/LI.kt#L18-L20