SLLI: Possibly wrong decoding?

[mablinov]

This concerns the SLLI encoding. From the spec, the rv32i SLLI instruction is encoded as follows:

So, the leftmost field has 7 bits of opcode space, and then theres a 5 bit shamt field.

As for the 64 bit variant, its encoded differently:

Now we only have 6 bits of opcode space on the left, because we steal one bit for the 64-bit shift amount encoding.

Now consider the following opcode:
0000000 11111 00000 001 00000 0010011 = 0x1F01013

The test.s:

.attribute arch, "rv32i"
start:
	.word 0x1F01013

disassembly:

00000000 <start>:
   0:	01f01013          	slli	zero,zero,0x1f

Ok, makes sense, we shift left by an immedate amount of 31 bits.
If we do the following however:

0000001 00000 00000 001 00000 0010011 = 0x2001013
We've "incremented" the shamt by one, but as per the rv32i v2.2 spec, the shamt is 0, and bit 0 of the leftmost opcode[6:0] field is now set, so it shouldn't be a "SLLI" anymore (atleast not in rv32i).

test.s:

.attribute arch, "rv32i"

start:
	.word 0x2001013

disassembling test.o:

test:
00000000 <start>:
   0:	02001013          	slli	zero,zero,0x20

That is SLLI in rv64i, but not in rv32i, right?

[mablinov]

Sorry if anyone saw the half-finished post, I accidently pressed ctrl-enter...

[aswaterman]

It's a "feature" of objdump that it will attempt to disassemble the instruction even though it's illegal in RV32I.
Yes, 0x02001013 is an illegal instruction in RV32I. GAS won't let you assemble the instruction slli x0,x0,32, but if objdump encounters the bit pattern that corresponds to that illegal instruction, it will still disassemble it.