slli.uw shifts 32 and higher not useful?
jim-wilson opened this issue · comments
slli.uw is a 32-bit zero extend followed by a shift, which means any shift count 32 or more will shift out all of the zero bits, and be redundant with a regular slli instruction. Hence it appears that only shift counts of 0 to 31 are useful. That would free up some opcode encoding space if we limited the shift count. We only need 5 bits for the shift count, not 7. We could make this easier to use if slli.uw with shift count 32 and higher is just an assembler alias for slli.
Looking forward to rv128, it would make sense to add a slli.ud instructrion which is a 64-bit zero-extend followed by a shift, and similarly would only need 6 bits not 7 bits for the shift count. Both slli.uw and slli.ud could be encoded in the existing space with the limited shift counts. For instance, if the two high bits of the shift count are 00 then it is slli.uw. If the two high bits of the shift count are 1X then it is slli.ud with one bit used for the shift count. Or we could reserve these encodings for some other use.
I generated a bitmanip.pdf file from an up-to-date copy of riscv-bitmanip. Chapter 2.12 Opcode Encodings has a 7-bit immediate field for all of the shift like instructions, including the shifts and rotates, the single-bit (zbs) instructions, the permutation instructions like gorci and grevi, and the slli.uw instruction. The only instructions with 6-bit immediates are SHFLI, UNSHFLI, and FSRI.
slli.uw with imm > 32 is only the same as slli on RV64.
On RV 128 slli.uw is the same as slli only if imm > 128 - 32 = 96, so on RV128 you do need 7 bit.
Rogier
The bitmanip spec does refer to RV128 in a number of places, but it hasn't tried to completely specify the RV128 B instruction set. For instnace, zext.d is defined using the hypothetical add.ud instruction, which isn't defined.
The bitmanip spec reserves 7 bits in the encoding for shift instructions. riscv-opcode only reserves 6 bits. I don't know why the change, maybe someone on the riscv-opcode side didn't understand why 7 bits were required. Or thought that we didn't need to define the RV128 support yet. The base spec doesn't explicitly define rv128 shifts, but it does say in the RVI128 Chapter 6 that shift use the low 7 bits of the immediate field, and if you look at the shift instruction encodings there is brownfield space in the encodings to make this work.
Hi Jim,
While we understand why 7 bits would be required for RV128, we are taking a wait-and-see approach, just as was done in the base architecture. This means that there is brownfield space to add the extra bit, should we need it. Likewise, we have not yet defined any .d instructions.