Clarify behavior of shift immediate operands

[JamesKenneyImperas]

I'm unsure about the intended design of instructions here that take immediate shift operands. At the moment this affects only slli.uw, but in future also gorci and grevi will be affected (when ratified).

In the base architecture, I think that when a shift amount (shamt) is encountered, this has to be in the range 0..XLEN-1, otherwise it is an Illegal Instruction. Historically, this hasn't been the case in this B extension; for example, in the previous 0.94 specification, slli.uw was defined like this:

uint_xlen_t slliuw(uint_xlen_t rs1, int imm)
{
uint_xlen_t rs1u = (uint32_t)rs1;
int shamt = imm & (XLEN - 1);
return rs1u << shamt;
}

With this decode:

| 00001 | imm | rs1 | 001 | rd | 0011011 | SLLI.UW

This allowed any 7-bit constant to be used and simply masked to the active XLEN, so no Illegal Instruction. Now, the decode of slli.uw has changed so that only a six-bit constant is allowed, and this is a shamt. I have three questions:

1. Is the reduction from 7 to 6 bits for this field intentional?
2. Is it expected that the field follows the standard shamt rules from the base architecture, so that if shamt >= 32 on RV32 this is an Illegal Instruction, or is it simply masked to 0...XLEN-1 as was the case in 0.94?
3. If the proposed behavior has changed from 0.94, will this also be the case for gorci and grevi?

Apologies if this has been discussed elsewhere: if so, can you point me at that.

Thanks.

[JamesKenneyImperas]

I just remembered that slli.uw is of course RV64 only, to the comments about RV32 don't apply.

I would still like to know the answer for questions 1 and 3.

Thanks.

[Philipp Tomsich]

On Wed 16. Jun 2021 at 12:23, JamesKenneyImperas ***@***.***> wrote: I'm unsure about the intended design of instructions here that take immediate shift operands. At the moment this affects only slli.uw, but in future also gorci and grevi will be affected (when ratified). In the base architecture, I think that when a shift amount (shamt) is encountered, this has to be in the range 0..XLEN-1, otherwise it is an Illegal Instruction. Historically, this hasn't been the case in this B extension; for example, in the previous 0.94 specification, slli.uw was defined like this: uint_xlen_t slliuw(uint_xlen_t rs1, int imm) { uint_xlen_t rs1u = (uint32_t)rs1; *int shamt = imm & (XLEN - 1)*; return rs1u << shamt; } With this decode: | 00001 | imm | rs1 | 001 | rd | 0011011 | SLLI.UW This allowed any 7-bit constant to be used and simply masked to the active XLEN, so no Illegal Instruction. Now, the decode of slli.uw has changed so that only a *six-bit* constant is allowed, and this is a shamt. I have three questions: 1. Is the reduction for 7 to 6 bits for this field intentional? 2. Is it expected that the field follows the standard shamt rules from the base architecture, so that if shamt >= 32 on RV32 this is an Illegal Instruction, or is it simply masked to 0...31 as was the case in 0.94? The opcode encoding in the specification sent for public review is to be

taken literally: only 6 bits are available for shamt in RV64 and the 7th bit is considered part of the functor (i.e., fixed at 0 for slli.uw). Given that we reserve (for the time being) the slli.uw-variant the functor having this bit set (for a future RV128), no other instruction (currently) is mapped to this pattern and it remains an illegal instruction.

…

1. If the proposed behavior has changed from 0.94, will this also be the case for gorci and grevi? Apologies if this has been discussed elsewhere: if so, can you point me at that. Thanks. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#146>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADSKDHXEHF7CKS2AENUO363TTB3RXANCNFSM46ZEAS2Q> .

[JamesKenneyImperas]

Ok, so you are saying that this is an intentional change from 0.94?

Thanks.

[Philipp Tomsich]

On Wed 16. Jun 2021 at 13:05, JamesKenneyImperas ***@***.***> wrote: Ok, so you are saying that this is an intentional change from 0.94?

Yes. Generally speaking, our future specifications should try to become more explicit about reserved encodings and valid encodings for RV32/RV64/future and hide fewer of these definitions in the descriptive text only.

[JamesKenneyImperas]

Do you know of any other intentional changes like this between 0.94 and 1.0.0? Is there a list somewhere I can see?

Thanks.

[Philipp Tomsich]

On Wed, 16 Jun 2021 at 13:18, JamesKenneyImperas ***@***.***> wrote: Do you know of any other intentional changes like this between 0.94 and 1.0.0? Is there a list somewhere I can see?

Due to the rush to get this changed over to ASCIIdoc, have a SAIL-like pseudo-language used, and to shrink this down to the ratification scope only, there probably isn't such a list anywhere. Given that 0.94-draft was never released as anything but a draft, creating such a list would have tried to hit a moving target. However, I would recommend taking a look at the shift-operands for the rotate instructions (immediate form) as well. Neither gorci nor grevi are not part of the ratification scope, but we only have orc.b and rev8. The two distinct rev8-encodings hint at the same treatment of the shamt-immediate in a theoretical grevi.

[JamesKenneyImperas]

Since there is no list of intentional changes like this between 0.94 and 1.0.0, I think I'll close this. My preliminary scan didn't find anything else that differed.

[Philipp Tomsich]

I came across this in some consistency checking of the document and can offer a bit more information...

The 0.93/0.94 version already had limited the width of immediates for RV32 and RV64 (see 2.12: "All shift instructions use funct3=001 for left shifts and funct3=101 for right shifts. Just like in the RISC-V integer base ISA, the shift-immediate instructions have a 5 bit immediate on RV32, and a 6 bit immediate on RV64, and we reserve encoding space for a 7 bit immediate for RV128."), but did not make it explicit that this would require raising an undefined instruction if the high bit is set for RV32.