Shifts on RV32I

[Paulo Matos]

Hi,

I was just reading through Patterson and Waterman book and noticed that
it says for slli shamt[5] on RV32I needs to be zero (i assume this is
the high order bit). I was quite surprised by this. So I picked up the
ISA 2.2 and on page 14 there's no mentioning this requirement. Is this
the case? Why?

On the other hand I got confused when reading this as it looks like
there are two opcodes SRLI and SRAI but also one bit (bit 30) that seems
to differentiate between these two. Why is this needed?

Kind regards,
--
Paulo Matos

[Alex Bradbury]

On 27 February 2018 at 12:37, 'Paulo Matos' via RISC-V ISA Dev

<isa...@groups.riscv.org> wrote:
> Hi,
>
> I was just reading through Patterson and Waterman book and noticed that
> it says for slli shamt[5] on RV32I needs to be zero (i assume this is
> the high order bit). I was quite surprised by this. So I picked up the
> ISA 2.2 and on page 14 there's no mentioning this requirement. Is this
> the case? Why?

On RV32, slli takes a 5-bit immediate (so shamt[5] is 0). On RV64, it
takes a 6-bit immediate, meaning shamt[5] can be set. Remember that
RV32I and RV64I are separate base ISAs, rather than it being
structured so that RV64 is an extension to RV32. Although this is
specified in the ISA manual, it's easy to be confused on this point
due to the fact that RV64I is presented as a diff to RV32I.

Best,

Alex

[Bruce Hoult]

It's not very useful to shift by more than 31 bits on a machine with 32 bit registers. Especially when it is an immediate shift, in which case the compiler can replace the operation by a constant 0 (or by a 31 bit shift in the case of SRAI).

You need to distinguish between SRAI and SRLI opcodes because they produce different results ... the new high bits are filled with 0's in one case and by duplicating the Most Significant Bit in the other case.

--
Paulo Matos

--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+unsubscribe@groups.riscv.org.
To post to this group, send email to isa...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/5ffe8279-a6d9-318a-d0fc-2f192b4b3ca3%40linki.tools.

[Paulo Matos]

Ah, thanks. Of course, my confusion was that in my mind I had that
shamt[5] was the highest order bit of the 5 bits for the shamt. But
obviously shamt[5] is the sixth bit.

Thanks,

--
Paulo Matos

[Paulo Matos]

On 27/02/18 15:00, Bruce Hoult wrote:
> It's not very useful to shift by more than 31 bits on a machine with 32
> bit registers. Especially when it is an immediate shift, in which case
> the compiler can replace the operation by a constant 0 (or by a 31 bit
> shift in the case of SRAI).
>

Yes, understood. As mentioned to Alex, I was confused as I thought
shamt[5] was the higher order bit of the 5 bits in the shamt. Didn't
notice that shamt[5] is actually the 6th bit, which I knew was unused
for RV32I.

> You need to distinguish between SRAI and SRLI opcodes because they
> produce different results ... the new high bits are filled with 0's in
> one case and by duplicating the Most Significant Bit in the other case.
>

Yes, but the question persists. There's a different opcode but ISA also
shows bit 30 being different. What differentiates between SRAI and SRLI?
Is it different opcode or bit 30 being set? It seems to be both. My
question is: why do we need a different opcode _and_ bit 30 set?

--
Paulo Matos

[Alex Bradbury]

On 27 February 2018 at 14:32, 'Paulo Matos' via RISC-V ISA Dev

<isa...@groups.riscv.org> wrote:
> Yes, but the question persists. There's a different opcode but ISA also
> shows bit 30 being different. What differentiates between SRAI and SRLI?
> Is it different opcode or bit 30 being set? It seems to be both. My
> question is: why do we need a different opcode _and_ bit 30 set?

We don't. I don't have a copy of the book you reference to hand to see
if it's an error in the book or a misreading, but take a look at page
104 in the canonical reference (the v2.2 user spec):
<https://content.riscv.org/wp-content/uploads/2017/05/riscv-spec-v2.2.pdf>.
Both srli and srai have opcode = 0010011 and funct3 = 101, differing
in bit 30.

I hope that helps.

Best,

Alex

[Jim Wilson]

On Tue, Feb 27, 2018 at 6:48 AM, Alex Bradbury <a...@asbradbury.org> wrote:
> On 27 February 2018 at 14:32, 'Paulo Matos' via RISC-V ISA Dev
> <isa...@groups.riscv.org> wrote:
>> Yes, but the question persists. There's a different opcode but ISA also
>> shows bit 30 being different. What differentiates between SRAI and SRLI?
>> Is it different opcode or bit 30 being set? It seems to be both. My
>> question is: why do we need a different opcode _and_ bit 30 set?

I assume you are looking at page 14, and reading it a bit too
literally. The func3 column lists SRLI and SRAI on separate lines,
but this is not an encoding, it is just a description of the
instructions. The instruction name has to appear somewhere on the
line, and they just put it in the func3 column instead of having a
separate possibly redundant column for the instruction name.

For the encoding, see Chapter 19, page 104, as Alex mentioned, and it
shows that SRLI and SRAI in the func 3 column have the same encoding.

Jim

[Paulo Matos]

On 27/02/18 16:28, Jim Wilson wrote:
> I assume you are looking at page 14, and reading it a bit too
> literally. The func3 column lists SRLI and SRAI on separate lines,
> but this is not an encoding, it is just a description of the
> instructions. The instruction name has to appear somewhere on the
> line, and they just put it in the func3 column instead of having a
> separate possibly redundant column for the instruction name.
>
> For the encoding, see Chapter 19, page 104, as Alex mentioned, and it
> shows that SRLI and SRAI in the func 3 column have the same encoding.
>

Ah, yes. That's correct. That was my issue. All cleared up now.

Many thanks,

--
Paulo Matos