compressed LI error -> AssemblerError: constraint failed: imm must not be 0

[theandrew168]

compressed LI error -> AssemblerError: constraint failed: imm must not be 0

[theandrew168]

Good catch! Could you provide the value you are using for gfx_data? I'm trying to replicate this but can't quickly find a value that triggers the error.

[enthusi]

Hi,
gfx_data is at 0x9f4 at the time of the bail out.

[theandrew168]

Hmm, assembling this instruction alone doesn't seem to trigger the error for me.

Here's the verbose output on my end:

bronzebeard --compress -v test.asm
reading file: /Users/steve/Code/bronzebeard/test.asm
parsed file test.asm, line 1: "li ['a6', '0x9f4']"
transform_pseudo_instructions: file test.asm, line 1: "li ['a6', '0x9f4']" -> "lui a6, %hi(0x9f4)"
transform_pseudo_instructions: file test.asm, line 1: "li ['a6', '0x9f4']" -> "addi a6, a6, %lo(0x9f4)"
resolve_compressible: file test.asm, line 1: "lui a6, %hi(0x9f4)" -> "c.lui a6, %hi(0x9f4)"
resolve_immediates: file test.asm, line 1: "c.lui a6, %hi(0x9f4)" -> "c.lui a6, 1"
resolve_immediates: file test.asm, line 1: "addi a6, a6, %lo(0x9f4)" -> "addi a6, a6, -1548"
resolve_instructions: file test.asm, line 1: "c.lui a6, 1" -> "blob 0x05 0x68"
resolve_instructions: file test.asm, line 1: "addi a6, a6, -1548" -> "blob 0x13 0x08 0x48 0x9f"

And the version I'm using (just to be sure we are on the same):

bronzebeard --version
bronzebeard 0.1.15

Does this error occur when you assemble the single instruction by itself? It not, could you produce a small reproduction example?

[enthusi]

I can reproduce it in my code any time.
Version 0.1.15 and the verbose output is:

python3 -m bronzebeard.asm --compress -l labels.asm -v term04.asm | grep gfx_data
parsed file term04.asm, line 634: "li ['a6', 'gfx_data']"
parsed file term04.asm, line 1024: "gfx_data:"
transform_pseudo_instructions: file term04.asm, line 634: "li ['a6', 'gfx_data']" -> "lui a6, %hi(gfx_data)"
transform_pseudo_instructions: file term04.asm, line 634: "li ['a6', 'gfx_data']" -> "addi a6, a6, %lo(gfx_data)"
resolve_compressible: file term04.asm, line 634: "lui a6, %hi(gfx_data)" -> "c.lui a6, %hi(gfx_data)"
resolve_immediates: file term04.asm, line 634: "c.lui a6, %hi(gfx_data)" -> "c.lui a6, 0"
resolve_immediates: file term04.asm, line 634: "addi a6, a6, %lo(gfx_data)" -> "addi a6, a6, 1912"
File "/home/martin/2022/nano_terminal/term04.asm", line 634
li a6, gfx_data
AssemblerError: constraint failed: imm must not be 0

BUT a6 is not supposed to be compressable in the first place!
Maybe that is another issue here?:

RVC Register Number 000 001 010 011 100 101 110 111
Integer Register Number x8 x9 x10 x11 x12 x13 x14 x15
Integer Register ABI Name s0 s1 a0 a1 a2 a3 a4 a5

It must have to do with things going on earlier in the code as it did assemble well before.
And it assembles well without --compress.

[enthusi]

I hit another of those, and this is simpler to understand:

li s0, lcd_init_data
AssemblerError: constraint failed: imm must not be 0

from label dump: lcd_init_data = 0x00000aec but this may not be the address at the very time of assembly of that line.

Verbose output:

resolve_compressible: file term04.asm, line 930: "lui s0, %hi(lcd_init_data)" -> "c.lui s0, %hi(lcd_init_data)"
resolve_immediates: file term04.asm, line 930: "c.lui s0, %hi(lcd_init_data)" -> "c.lui s0, 0"
resolve_immediates: file term04.asm, line 930: "addi s0, s0, %lo(lcd_init_data)" -> "addi s0, s0, 2030"
File "/home/martin/2022/nano_terminal/term04.asm", line 930
  li s0, lcd_init_data
AssemblerError: constraint failed: imm must not be 0

-> c.lui s0, 0 is the issue. Not sure why it even tries. And why it didnt fail much earlier, probably at 'suitable' values it loads something into upper and substracts rather that adding to 0?
This is a working (ugly) workaround:

lui s0, 0
addi s0, s0, lcd_init_data

[theandrew168]

Ahh, yea so the --compress flag accepting a6 is indeed a bug. For some instructions that disallow certain regs, I forgot to ALSO check that the regs are within the x8-x15 range of "common" instructions. I'll get that fixed here soon.

Relevant criteria for selecting c.lui can be seen here. Note the lack of RegBetween. This bug affects any compressed instruction that doesn't already have RegBetween or RegEquals.

I'm still unable to recreate this error locally. There is logic in place to only expand li into the correct number of real instructions depending on the immediate value being loaded. This code can be seen here. There is definitely another bug hiding in here somewhere but I can't seem to find a specific immediate value that triggers it!

[enthusi]

Hi, I wrote two test scripts in python:
This first is this:

source=open('brute_test_01.asm','w')
for i in range(0x1100):
    source.write('\t li s0, 0x%04x\n' % i)

This assembles well and LUI never loads 0 (it is interessting to see how it behaves though).
The second test fails:

source=open('brute_test_02.asm','w')
for i in range(0x1100):
    source.write('\t li s0, label%04x\n' % i)
for i in range(0x1100):
    source.write('label%04x:\n\t db 0\n' % i)

And results in:

python3 -m bronzebeard.asm --compress -l labels.asm   brute_test_02.asm 
File "/home/martin/2022/nano_terminal/brute_test_02.asm", line 3808
  li s0, label0edf
AssemblerError: 6-bit immediate must be between -0x20 (-32) and 0x1f (31): -1095

Which is possibly not THE bug, but could help tracking it down further.
Fixing bronzebeard into perfection would be greatly appreciated - I am currently using it for a bit larger project :)
Thank you very much!

[theandrew168]

Interesting. This is the most recent script that I tried:

with open('test.asm', 'w') as f:
    for i in range(0x4001):
        f.write('li s0 0x{:04x}\n'.format(i))
        f.write('li a0 0x{:04x}\n'.format(i))

This assembles an li for all immediate values within [0x0000, 0x4000]. Even with --compress, no errors arise. Also, I double checked that c.lui actually does allow a6 as a valid reg. Some compressed instructions allow for full 5-bit registers while others are restricted to the 3-bit "common" registers.

Since this example program doesn't trigger the bug, maybe it is coming from somewhere else and the errors we've been seeing are red herrings? I want bronzebeard to as accurate and correct as possible.

I'm going to play with your second example more and see if that leads me anywhere.

[theandrew168]

I think I've narrowed this issue down to an interaction between the transformation of psuedo and compressible instructions and how subsequent labels are reduced to compensate. The assembler is initially pessimistic about the size of things: li, call, tail are assumed to be 8 bytes until proven smaller, and compressed instructions shrink from 4 bytes down to 2. There must be some incorrect math or state handling somewhere.

[enthusi]

Yes, that sounds quite likely. Have you tried my second python script? It DID provoke an error.
Unfortunately in my growing code the issue came and went twice so far and I can not easily get back to it now (as things shift all the time).
Next time I hit it, I will commit the state and send it to you if you want (the full code).

[theandrew168]

Yea, I'm studying the second example quite a bit. I'm also trying to come up with a smaller reproducer but not having much luck there. I'll keep digging.

That'd be great, yea. Assuming I can't resolve things before it pops up again.

[theandrew168]

I'm going to close this for now until it pops up again or I (or anyone) can whip up a minimal reproducer.