3 ms·

There are a lot of things about the RISCV design that come from a very ideological place and hurt in a high end design. Yes, there are extensions and designs w

There are a lot of things about the RISCV design that come from a very ideological place and hurt in a high end design. Yes, there are extensions and designs with high end features, that's certainly true, and I'm sure people someone will be making a high end version at some point. But the ISA isn't very well suited to it compared to Power or ARM. By default, code density on RISC-V is pretty bad. You can try to solve that by using variable length instructions which many high end RISC-V projects intend to do but having variable length instructions means your front end is going to have to be more complicated to reach the same level of performance that a fixed width instruction machine can achieve. More instructions for a task means your back end also has to execute more instructions to reach the same level of performance. One way to do better is to fuse together ISA-level instructions into a smaller number of more complex instructions that get executed in your core. This is something that basically every high end design does but RISC-V would have to do it far more extensively than other architectures to achieve a similar level of density on the back end which makes designing a high end core more complex and possibly uses extra pipeline stages making mispredicts more costly. And more more criticisms here: https://gist.github.com/erincandescent/8a10eeeea1918ee4f9d9982f7618ef68 https://gist.github.com/erincandescent/8a10eeeea1918ee4f9d99... EDIT: But in fairness it looks like conditional move might be getting added to the bit manipulation RISC-V extension which would fix one big pain point. This isn't to say that RISC-V is bad. It's simplicity makes it wonderful for low end designs. It's extensibility makes it great for higher level embedded uses where you might want to add some instruction that makes your life easier for your hard driver controller or whatever in a way that would require a very expensive architecture license if you were using ARM. It's open, which would be great if you were making a high end open-source core for other people to use except the Power ISA just opened up so if I were to start a project like that I'd use that instead.

zozbot234 7y ago
> By default, code density on RISC-V is pretty bad. Code density with the C extension is competitive with x86, which is very good for a RISC. And the C extension is not even that hard on the decoder, since most or even all 'compressed' instructions have a single uncompressed counterpart. It's easier to implement than what ARM32 does with Thumb. > One way to do better is to fuse together ISA-level instructions into a smaller number of more complex instructions that get executed in your core. Insn fusion has in fact been endorsed by the designers of RISC-V as an expected approach in high-end designs. The RISC-V spec even gives "suggested" sequences for things like overflow checking, that can be transparently insn-fused if an implementation supports it.
- Symmetry 7y ago
  Yes, RISC-V's instruction compression is easier to use than Thumb. But there's a reason no arm server uses compressed instructions and ARM dropped it from A64.
  - atq2119 7y ago
    Enlighten us: what is that reason?
    - Symmetry 7y ago
      As far as I can tell the reason is that with variable length instructions you have a mux layer between fetch and decode that sends the right set of bytes to the right decode slot. Your first set of 16 bits is certainly going into the first decoder but your fourth might be going to the second, third, or fourth depending on previous decoding. Or maybe not, I've only worked with fixed width instructions when getting into the weeds of processors and only entirely designed a simple five stage classic RISC myself. So don't take the above too seriously. What you should take seriously is that three of the four big RISC ISAs - MIPS, ARM, and POWER - all have extensions for variable length instructions. They all use them in embedded systems where program memory size is a big factor in your bill of materials and reducing that can save you money. But none of them use it on their high end processors. So I think we can conclude that the power/transistor cost of fetching a number of variable length instructions per clock is higher than the cost of expanding the L1 instruction cache to deal with full size instructions.
      - monocasa 7y ago
        At most, you're looking at an extra pipeline stage for all of that. The less I$ pressure is almost certainly worth it. The real cost you're looking at is the complexity for instructions to straddle cache lines and MMU pages, but even then it's less of a deal than you might think.
        Taniwha 7y ago

zozbot234 7y ago

> By default, code density on RISC-V is pretty bad. Code density with the C extension is competitive with x86, which is very good for a RISC. And the C extension is not even that hard on the decoder, since most or even all 'compressed' instructions have a single uncompressed counterpart. It's easier to implement than what ARM32 does with Thumb. > One way to do better is to fuse together ISA-level instructions into a smaller number of more complex instructions that get executed in your core. Insn fusion has in fact been endorsed by the designers of RISC-V as an expected approach in high-end designs. The RISC-V spec even gives "suggested" sequences for things like overflow checking, that can be transparently insn-fused if an implementation supports it.

Symmetry 7y ago
Yes, RISC-V's instruction compression is easier to use than Thumb. But there's a reason no arm server uses compressed instructions and ARM dropped it from A64.
- atq2119 7y ago
  Enlighten us: what is that reason?
  - Symmetry 7y ago
    As far as I can tell the reason is that with variable length instructions you have a mux layer between fetch and decode that sends the right set of bytes to the right decode slot. Your first set of 16 bits is certainly going into the first decoder but your fourth might be going to the second, third, or fourth depending on previous decoding. Or maybe not, I've only worked with fixed width instructions when getting into the weeds of processors and only entirely designed a simple five stage classic RISC myself. So don't take the above too seriously. What you should take seriously is that three of the four big RISC ISAs - MIPS, ARM, and POWER - all have extensions for variable length instructions. They all use them in embedded systems where program memory size is a big factor in your bill of materials and reducing that can save you money. But none of them use it on their high end processors. So I think we can conclude that the power/transistor cost of fetching a number of variable length instructions per clock is higher than the cost of expanding the L1 instruction cache to deal with full size instructions.
    - monocasa 7y ago
      At most, you're looking at an extra pipeline stage for all of that. The less I$ pressure is almost certainly worth it. The real cost you're looking at is the complexity for instructions to straddle cache lines and MMU pages, but even then it's less of a deal than you might think.
      - Taniwha 7y ago