5 ms·

One concrete advantage RISCV has is its variable-length SIMD instruction set. The assembly instructions used for SIMD in RISCV can all operate on data sizes tha

One concrete advantage RISCV has is its variable-length SIMD instruction set. The assembly instructions used for SIMD in RISCV can all operate on data sizes that are various powers of 2. All using the same instructions. You could even call it “SIMD with dynamically-sized data”. Right now, x86 needs one set of instructions for each SIMD data size. That’s why we have SSE, AVX, AVX512, etc. This introduces complexity for both hardware designers and software designers. You have to actively update software to work with newer chips with larger SIMD registers. In the proposed RISCV design, you wouldn’t have to. It would just work on all sizes.

lopmotr 6y ago
Wow, I didn't realize how many of these x86 extensions are basically just SIMD with more and more registers, even going back to MMX in the 1990's. It somehow looks like they never planned ahead and just kept re-inventing a slightly bigger wheel. Great to see RISC-V does it in a unified way.
- jlokier 6y ago
  To be fair to x86, each new generation of SIMD added new kinds of arithmetic & logic operations too, not just wider registers. RISC-V will need to do the same, so expect to see multiple versions of the "V" extension over time.
userbinator 6y ago
Right now, x86 needs one set of instructions for each SIMD data size. If you look at the encodings, many of them are actually the same opcodes as the original MMX, but with prefixes. In the proposed RISCV design, you wouldn’t have to. It would just work on all sizes. That doesn't make sense --- how would the code know how much to increment pointers by, how many times to loop, alignment, etc. ? Unless they added some really un-RISC instructions to do automatic vectored operations (like if x86 had a REP ADDSB), I don't see how you wouldn't need to change software for changing SIMD widths.
- monocasa 6y ago
  > That doesn't make sense --- how would the code know how much to increment pointers by, how many times to loop, alignment, etc. ? You ask the hardware. The current vector width is a register that can be set and queried. https://gms.tf/riscv-vector.html https://gms.tf/riscv-vector.html
  - userbinator 6y ago
    That is interesting... and actually feels a bit CISCy, but this Configuring a grouping of 8 registers for a vector of 16 elements might look like overkill because 128 bit vector registers are sufficient and should be widely available. On the other hand, there might be a CPU with "V" support that just implements - say - 64 bit vector registers where we would need to group 2 registers. Since a grouping thus may be needed it really doesn't hurt to configure the maximum here. ...seems to imply that the generated code may still need to assume certain widths.
    - brucehoult 6y ago
      No, it doesn't imply that. It's just that if your code doesn't need 32 different vector variables then you can step down to, say, 4 variables with 8x longer registers for more efficiency. You need to know how many live variables your code has (which the compiler knows), not how long the registers are.
floatboth 6y ago
Arm SVE is also variable data size, and it's already in production on Fujitsu's massive HPC clusters :P
- brucehoult 6y ago
  SVE looks pretty good. But ARM themselves are showing absolutely no signs of incorporating it into any of their own cores, despite the specs being published as part of ARMv8.2-A in January 2016. They're up to ARMv8.6-A now, with 8.7 or maybe ARMv9 expected any time.

lopmotr 6y ago

Wow, I didn't realize how many of these x86 extensions are basically just SIMD with more and more registers, even going back to MMX in the 1990's. It somehow looks like they never planned ahead and just kept re-inventing a slightly bigger wheel. Great to see RISC-V does it in a unified way.

jlokier 6y ago
To be fair to x86, each new generation of SIMD added new kinds of arithmetic & logic operations too, not just wider registers. RISC-V will need to do the same, so expect to see multiple versions of the "V" extension over time.

userbinator 6y ago

Right now, x86 needs one set of instructions for each SIMD data size. If you look at the encodings, many of them are actually the same opcodes as the original MMX, but with prefixes. In the proposed RISCV design, you wouldn’t have to. It would just work on all sizes. That doesn't make sense --- how would the code know how much to increment pointers by, how many times to loop, alignment, etc. ? Unless they added some really un-RISC instructions to do automatic vectored operations (like if x86 had a REP ADDSB), I don't see how you wouldn't need to change software for changing SIMD widths.

monocasa 6y ago
> That doesn't make sense --- how would the code know how much to increment pointers by, how many times to loop, alignment, etc. ? You ask the hardware. The current vector width is a register that can be set and queried. https://gms.tf/riscv-vector.html https://gms.tf/riscv-vector.html
- userbinator 6y ago
  That is interesting... and actually feels a bit CISCy, but this Configuring a grouping of 8 registers for a vector of 16 elements might look like overkill because 128 bit vector registers are sufficient and should be widely available. On the other hand, there might be a CPU with "V" support that just implements - say - 64 bit vector registers where we would need to group 2 registers. Since a grouping thus may be needed it really doesn't hurt to configure the maximum here. ...seems to imply that the generated code may still need to assume certain widths.
  - brucehoult 6y ago
    No, it doesn't imply that. It's just that if your code doesn't need 32 different vector variables then you can step down to, say, 4 variables with 8x longer registers for more efficiency. You need to know how many live variables your code has (which the compiler knows), not how long the registers are.

floatboth 6y ago

Arm SVE is also variable data size, and it's already in production on Fujitsu's massive HPC clusters :P

brucehoult 6y ago
SVE looks pretty good. But ARM themselves are showing absolutely no signs of incorporating it into any of their own cores, despite the specs being published as part of ARMv8.2-A in January 2016. They're up to ARMv8.6-A now, with 8.7 or maybe ARMv9 expected any time.