What's the purpose of SRA[I]W?

[Kelly Dean]

The purpose of the *W computation instructions in RV64 is to operate on 32-bit values. The spec (v2.2, p. 29) says all 32-bit values, both signed and unsigned, are supposed to be in sign-extended format on RV64, and the rest of chapter 4 says all the *W instructions, including LW, do sign-extend them.

For any 32-bit value thus formatted, SRA[I] does the same thing as SRA[I]W. It'll only do something different if the value is improperly formatted, e.g.
t0=0000_0000_8000_0000
srai t1, t0, 1 → 0000_0000_4000_0000
sraiw t1, t0, 1 → FFFF_FFFF_C000_0000

But the only cause of t0 being improperly formatted would be a bug in the prior code (by using a non-W instruction where a *W should have been used).

Unlike SRA[I], the rest of the non-W instructions do different things, even on properly formatted 32-bit values, than the *W instructions do, which is why the latter are included in RV64. But why is SRA[I]W included?

[Andrew Waterman]

As you pointed out, the behavior differs if the input isn’t already canonicalized. So, you can truncate to 32-bit and do a right shift with a single instruction.

In general, the *W instructions don’t require their inputs be canonicalized. It is the ABI, not the ISA, that requires that 32-bit values be canonicalized.

--
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+u...@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/3ahspEuIEjZZNIji8mgRoUbzzVn0KO45V1w2gk8IfpP%40local.

[Bruce Hoult]

Further to Andrew's comments: a compiler can often get considerable performance improvements by NOT canonicalizing every intermediate result, but only at the end of a series of calculations. As long as the compiler can prove that the end result is the same.

On RISC-V there is not much problem mixing 32 bit and 64 bit signed values. But if the code the programmer writes mixes operations on 32 bit and 64 bit unsigned values then every cast or assignment between them costs a SLL/SRL pair.

Aarch64 has the opposite problem ... mixing 32 bit and 64 bit unsigned works great, but mixing 32 bit and 64 bit signed needs a lot of explicit sign-extension. They get off a bit lighter, with sign extension (or truncation) being a single instruction operation (a special case of the Bitfield Move instruction).

You could say "Don't write code like that", but unfortunately this badly hits RISC-V performance on some benchmarks that potential RISC-V adoptees are using. It's probably in a lot of real code in the wild too.

So, the compiler needs to be free to not canonicalize all intermediate results, but only at ABI interfaces.

On Wed, Mar 7, 2018 at 7:48 PM, Andrew Waterman <wate...@eecs.berkeley.edu> wrote:

As you pointed out, the behavior differs if the input isn’t already canonicalized. So, you can truncate to 32-bit and do a right shift with a single instruction.

In general, the *W instructions don’t require their inputs be canonicalized. It is the ABI, not the ISA, that requires that 32-bit values be canonicalized.

On Wed, Mar 7, 2018 at 8:31 AM Kelly Dean <ke...@prtime.org> wrote:

The purpose of the *W computation instructions in RV64 is to operate on 32-bit values. The spec (v2.2, p. 29) says all 32-bit values, both signed and unsigned, are supposed to be in sign-extended format on RV64, and the rest of chapter 4 says all the *W instructions, including LW, do sign-extend them.

For any 32-bit value thus formatted, SRA[I] does the same thing as SRA[I]W. It'll only do something different if the value is improperly formatted, e.g.
t0=0000_0000_8000_0000
srai t1, t0, 1 → 0000_0000_4000_0000
sraiw t1, t0, 1 → FFFF_FFFF_C000_0000

But the only cause of t0 being improperly formatted would be a bug in the prior code (by using a non-W instruction where a *W should have been used).

Unlike SRA[I], the rest of the non-W instructions do different things, even on properly formatted 32-bit values, than the *W instructions do, which is why the latter are included in RV64. But why is SRA[I]W included?

--
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/3ahspEuIEjZZNIji8mgRoUbzzVn0KO45V1w2gk8IfpP%40local.

--

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/CA%2B%2B6G0AgO4AQ1NJDH90fzC%3DMyGnuNjA6YSVgDUDVJOVB7fJrSg%40mail.gmail.com.