10 ms·

I don't see why macro-op fusion should be harder for RISC-V than x86. x86 ISA was designed without this in mind. The RISC-V designers in contrast seem to delibe

I don't see why macro-op fusion should be harder for RISC-V than x86. x86 ISA was designed without this in mind. The RISC-V designers in contrast seem to deliberately design instructions to make it easier to perform macro-op fusion. You can see specific revisions to the spec being made to make macro-op fusion easier. Actual real world performance tests already suggests that RISC-V tend to require less memory for their programs as well as fewer instructions than x86 and ARM. Hence even without pervasive macro-op fusion they are in a good spot. E.g. for CoreMark used to benchmark embedded processors RISC-V BOOM implementation came ahead ARM-32 Cortex-A9 with about 10% fewer instructions, 10% smaller memory usage and about 10% higher clock frequency (thanks to smaller core).

rwallace 6y ago
How? I was under the impression that RISC-V was deliberately minimalist in the hope of obtaining smaller cores, and I can see how that would allow higher clock frequency, but I would've expected the trade-off to be longer programs. How did it get shorter programs than ARM? What were the cases where a single RISC-V instruction corresponded to multiple ARM instructions?
- legulere 6y ago
  The most common instructions have a compressed 16 bit representation. The compressed instructions are optional though and simple cores just have to support 32 bit instructions.
- socialdemocrat 6y ago
  A lot of it is about having shorter versions for frequently used instructions. E.g. compare and branch is just one instruction on RISC-V. More complex instructions simply are not used frequently so their ability to reduce code size isn't as big as people think. In addition RISC-V has twice as many registers as ARM-32 Cortex-A9, which the particular CoreMark was comparing against. Also a different ABI conventions reduce the number of instructions spent on saving and restoring registers. E.g. RISC-V has certain registers marked as saved, temporary, arguments etc. Then of course for RISC-V it isn't expensive to support compressed instructions. You use the same decoder not different modes and different decoders like ARM. Just 400 gates to implement, so it is kind of a no-brainer. If comparing SPEC CPU2006 benchmark code using GCC compiler then uncompressed RISC-V vs uncompressed ARM is basically the same. Compressed RISC-V and compressed ARM is basically the same. The latter beats x86 by about 26%. Uncompressed RISC-V is just 8% bigger than x86. So I would say in general RISC-V is paying a very small price for its simplicity. One could say there is a benefit in being able to learn from past mistakes.
berkut 6y ago
This paper here: https://carrv.github.io/2020/papers/CARRV2020_paper_12_Perotti.pdf https://carrv.github.io/2020/papers/CARRV2020_paper_12_Perot... seems to show that RISC-V has code density ~11% worse than ARM (although against Thumb2, so not 64-bit)...

rwallace 6y ago

How? I was under the impression that RISC-V was deliberately minimalist in the hope of obtaining smaller cores, and I can see how that would allow higher clock frequency, but I would've expected the trade-off to be longer programs. How did it get shorter programs than ARM? What were the cases where a single RISC-V instruction corresponded to multiple ARM instructions?

legulere 6y ago
The most common instructions have a compressed 16 bit representation. The compressed instructions are optional though and simple cores just have to support 32 bit instructions.
socialdemocrat 6y ago
A lot of it is about having shorter versions for frequently used instructions. E.g. compare and branch is just one instruction on RISC-V. More complex instructions simply are not used frequently so their ability to reduce code size isn't as big as people think. In addition RISC-V has twice as many registers as ARM-32 Cortex-A9, which the particular CoreMark was comparing against. Also a different ABI conventions reduce the number of instructions spent on saving and restoring registers. E.g. RISC-V has certain registers marked as saved, temporary, arguments etc. Then of course for RISC-V it isn't expensive to support compressed instructions. You use the same decoder not different modes and different decoders like ARM. Just 400 gates to implement, so it is kind of a no-brainer. If comparing SPEC CPU2006 benchmark code using GCC compiler then uncompressed RISC-V vs uncompressed ARM is basically the same. Compressed RISC-V and compressed ARM is basically the same. The latter beats x86 by about 26%. Uncompressed RISC-V is just 8% bigger than x86. So I would say in general RISC-V is paying a very small price for its simplicity. One could say there is a benefit in being able to learn from past mistakes.

berkut 6y ago

This paper here: https://carrv.github.io/2020/papers/CARRV2020_paper_12_Perotti.pdf https://carrv.github.io/2020/papers/CARRV2020_paper_12_Perot... seems to show that RISC-V has code density ~11% worse than ARM (although against Thumb2, so not 64-bit)...