6 ms·

They had one job: make it similar to ARMv8-A but not too similar to give ARM any ideas. Look at SSE4/AVX2 and NEON and make sufficiently similar vector extensio

They had one job: make it similar to ARMv8-A but not too similar to give ARM any ideas. Look at SSE4/AVX2 and NEON and make sufficiently similar vector extensions to that as well. So far RISC-V has failed miserably at both. "Just solve it in decoder", "just fuse common idioms", "just make vsetvli fast". Sure. Not like designers of ARMv8 or X86S had decades of prior experience to make better decisions.

onjectic 2y ago
"Just solve it in decoder" is a perfectly valid approach for now, and if this turns out to be unrealistic then they can go ahead and add a conditional move extension or whatever it is. It’s far easier to add things to interfaces than remove them. One mistake they have made that may bite them later is their compressed instructions extension. It takes up far too much of the instruction set space for the amount of utility it provides, even on microcontrollers in my opinion. It also introduces lots of edge cases around word alignment across cache and memory protection boundaries.
- brucehoult 2y ago
  Point of order! The RISC-V C extension takes up 75% of the opcode space. The 16 bit Thumb1 instructions take up 87.5% of the ARMv7 opcode space. Not to mention predication taking up 92.75% of the classic ARMv1-ARMv6 instruction set. RISC-V has comparatively twice as much "32 bit" opcode space as ARMv7, and 3.45x more than classic ARM A32.
brucehoult 2y ago
Point of order! The core of the RISC-V ISA was already designed by the time ARMv8-A was announced on 27 October 2011. I don't think anyone anticipated it -- certainly I remember it being a complete surprise to me. Here is the RISC-V design as at 13 May 2011: https://people.eecs.berkeley.edu/~krste/papers/EECS-2011-62.pdf https://people.eecs.berkeley.edu/~krste/papers/EECS-2011-62.... Compare that to the design eventually ratified in 2019 and you'll find some changes in details, but not in concept. - instructions encodings changed to e.g. put rd on the right next to the opcode and the MSBs of literals on the left. - J and JAL are now combined - JALR had three versions (in func3) to distinguish call / return / others. This is now done as a convention which registers are used in rd and rs1. (It matters only for a return address prediction stack, an advanced feature) - RDNPC (get address of next instruction) later turned into AUIPC (which includes adding an offset to the PC) - on the other hand, it already has the very RISC-V feature of loads using rd and rs1 while stores use rs1 and rs2 (and the offset split up differently). Most other ISAs (including all Arm ISAs) use the same register fields for loads and stores and the offset in the same place, resulting in either loads using rs2 as the destination or stores using rd as a source! Seriously, other than the changes mentioned above, this document looks just like the final RV32G/RV64G spec from ratification in 2019. (I didn't check the floating point instructions in detail). As for SIMD -- RISC-V was designed as the control processor for an advanced length agnostic vector processor. F*ck fixed length SIMD.
- neonsunset 2y ago
  > F*ck fixed length SIMD. There is the issue. It goes completely against how the current landscape of SIMD support looks like and what everything is optimized around (it's fixed length SIMD, variable length has huge issues getting mapped onto anything that isn't auto-vectorization). Now, I'm not a fan of RISC-V so, if anything, I encourage their way of doing RVV. Makes it more likely to die.
  - brucehoult 2y ago
    I don't see how it will die when it can imitate fixed length SIMD very easily. Not to mention that Arm too is pushing length-agnostic vector computing -- not very hard so far, admittedly, and they haven't yet departed from the 128 bit NEON vector register length. The very first SVE implementation, by Fujitsu, used 512 bit vector registers. And was the fastest supercomputer in the world for a while, so the concept is not obviously rubbish.
    - dzaima 2y ago
      RVV can imitate NEON, but will it perform anywhere near reasonably on hardware? With NEON, you can be sure that the hardware will be optimized around 128-bit operations and thus comfortably use it for such. Whereas RISC-V hardware with 512-bit vectors might only get quarter throughput if you only need the low 128 bits (and that could end up slower than doing scalar code! whereas on ARM you can be pretty damn sure than 1×128-bit NEON won't be slower than 2×64-bit scalar or some SWAR). Much as I like RVV, fixed-width use-cases still exist and are pretty important for CPU SIMD; scalable vectors work well for very-many-iteration embarrassingly parallel loops, but those are also things most suited for being moved to a GPU. Where CPUs have the most potential is in things with some dependency chain or small loops, for which scalable vectors largely just add questionability of performance.
      - brucehoult 2y ago
        Obviously using 128 bit vector length on a machine with 512 bit vector registers is not using all the performance you paid for, but it's not going to be slower than using a machine with 128 bit vector registers! Parallel operation on multiple data items is parallel operation on multiple data items. The developers of the dav1d software AV1 decoder found that RVV on a Kendryte K230 [1] performed no worse than NEON on an A53 on their small fixed-size transforms on video CODEC blocks. https://www.youtube.com/watch?v=asRnBcn5VKs&t=9m40s https://www.youtube.com/watch?v=asRnBcn5VKs&t=9m40s [1] THead C908 core, very similar to the old C906 core found in e.g. the $3 Milk-V Duo, but dual-issue and with the RVV updated from draft 0.7 to ratified 1.0

onjectic 2y ago

"Just solve it in decoder" is a perfectly valid approach for now, and if this turns out to be unrealistic then they can go ahead and add a conditional move extension or whatever it is. It’s far easier to add things to interfaces than remove them. One mistake they have made that may bite them later is their compressed instructions extension. It takes up far too much of the instruction set space for the amount of utility it provides, even on microcontrollers in my opinion. It also introduces lots of edge cases around word alignment across cache and memory protection boundaries.

brucehoult 2y ago
Point of order! The RISC-V C extension takes up 75% of the opcode space. The 16 bit Thumb1 instructions take up 87.5% of the ARMv7 opcode space. Not to mention predication taking up 92.75% of the classic ARMv1-ARMv6 instruction set. RISC-V has comparatively twice as much "32 bit" opcode space as ARMv7, and 3.45x more than classic ARM A32.

brucehoult 2y ago

Point of order! The core of the RISC-V ISA was already designed by the time ARMv8-A was announced on 27 October 2011. I don't think anyone anticipated it -- certainly I remember it being a complete surprise to me. Here is the RISC-V design as at 13 May 2011: https://people.eecs.berkeley.edu/~krste/papers/EECS-2011-62.pdf https://people.eecs.berkeley.edu/~krste/papers/EECS-2011-62.... Compare that to the design eventually ratified in 2019 and you'll find some changes in details, but not in concept. - instructions encodings changed to e.g. put rd on the right next to the opcode and the MSBs of literals on the left. - J and JAL are now combined - JALR had three versions (in func3) to distinguish call / return / others. This is now done as a convention which registers are used in rd and rs1. (It matters only for a return address prediction stack, an advanced feature) - RDNPC (get address of next instruction) later turned into AUIPC (which includes adding an offset to the PC) - on the other hand, it already has the very RISC-V feature of loads using rd and rs1 while stores use rs1 and rs2 (and the offset split up differently). Most other ISAs (including all Arm ISAs) use the same register fields for loads and stores and the offset in the same place, resulting in either loads using rs2 as the destination or stores using rd as a source! Seriously, other than the changes mentioned above, this document looks just like the final RV32G/RV64G spec from ratification in 2019. (I didn't check the floating point instructions in detail). As for SIMD -- RISC-V was designed as the control processor for an advanced length agnostic vector processor. F*ck fixed length SIMD.

neonsunset 2y ago
> F*ck fixed length SIMD. There is the issue. It goes completely against how the current landscape of SIMD support looks like and what everything is optimized around (it's fixed length SIMD, variable length has huge issues getting mapped onto anything that isn't auto-vectorization). Now, I'm not a fan of RISC-V so, if anything, I encourage their way of doing RVV. Makes it more likely to die.
- brucehoult 2y ago
  I don't see how it will die when it can imitate fixed length SIMD very easily. Not to mention that Arm too is pushing length-agnostic vector computing -- not very hard so far, admittedly, and they haven't yet departed from the 128 bit NEON vector register length. The very first SVE implementation, by Fujitsu, used 512 bit vector registers. And was the fastest supercomputer in the world for a while, so the concept is not obviously rubbish.
  - dzaima 2y ago
    RVV can imitate NEON, but will it perform anywhere near reasonably on hardware? With NEON, you can be sure that the hardware will be optimized around 128-bit operations and thus comfortably use it for such. Whereas RISC-V hardware with 512-bit vectors might only get quarter throughput if you only need the low 128 bits (and that could end up slower than doing scalar code! whereas on ARM you can be pretty damn sure than 1×128-bit NEON won't be slower than 2×64-bit scalar or some SWAR). Much as I like RVV, fixed-width use-cases still exist and are pretty important for CPU SIMD; scalable vectors work well for very-many-iteration embarrassingly parallel loops, but those are also things most suited for being moved to a GPU. Where CPUs have the most potential is in things with some dependency chain or small loops, for which scalable vectors largely just add questionability of performance.
    - brucehoult 2y ago
      Obviously using 128 bit vector length on a machine with 512 bit vector registers is not using all the performance you paid for, but it's not going to be slower than using a machine with 128 bit vector registers! Parallel operation on multiple data items is parallel operation on multiple data items. The developers of the dav1d software AV1 decoder found that RVV on a Kendryte K230 [1] performed no worse than NEON on an A53 on their small fixed-size transforms on video CODEC blocks. https://www.youtube.com/watch?v=asRnBcn5VKs&t=9m40s https://www.youtube.com/watch?v=asRnBcn5VKs&t=9m40s [1] THead C908 core, very similar to the old C906 core found in e.g. the $3 Milk-V Duo, but dual-issue and with the RVV updated from draft 0.7 to ratified 1.0