3 ms·

Mainly, richer addressing modes. SiFive designed RISC-V to have braindead-level simple addressing modes, with the idea that you use 2-4 normal alu ops to do ad

Mainly, richer addressing modes. SiFive designed RISC-V to have braindead-level simple addressing modes, with the idea that you use 2-4 normal alu ops to do addressing instead of a single op with a more complicated addressing mode. Then, to reduce the horrible impact this has on code size, they introduced the C extension that burns 75% of the encoding space of 32-bit instructions on 16-bit instructions, but this is still only a bandaid and a much weaker solution than having better addressing modes in the first place.

camel-cdr 2y ago
It's not as black and white as you portray it. Both sides of the argument agree that high-performance implementations are doable and not hindered much buy both, you can watch the debate in the profiles SIG zoom meetings. I think the real dispute was how the opcode space and code density will evolve when more and more extension will need to be added. Will more 32 opcode space and aligned 64 bit instructions but no 16 and no 48 bit instructions in the longterm be a better choice than fewer 32 bit instructions, but 16/48/64 bit instructions? Qualcomm is also currently involved in the Combined Instructions SIG, and proposed a few instructions in that vain: https://docs.google.com/spreadsheets/d/1dQYU7QQ-SnIoXp9vVvVjS6Jz9vGWhwmsdbEOF3JBwUg/edit#gid=0 https://docs.google.com/spreadsheets/d/1dQYU7QQ-SnIoXp9vVvVj.... Notice that these are currently very mild combined instructions, like BEQI, or CLO, which are unlikely to be cracked into uops compared to more complex addressing modes (e.g. apple silicon needs to crack pre/post increment load/stores). BTW, this article is actually about removing Qualcomm specific stuff from android, see: https://lists.riscv.org/g/sig-android/topic/105816077#msg389 https://lists.riscv.org/g/sig-android/topic/105816077#msg389
dzaima 2y ago
RISC-V already has an extension for simplifying address calculations, Zba, required for RVA23, for doing x*2+y, x*4+y, and x*8+y in a single instruction (sh1add/sh2add/sh3add; these don't have compressed variants, so always 4 bytes). Combined with the immediate offset in load/store instructions, that's two instructions (6 or 8 bytes depending on whether the load/store can be compressed) for any x86 mov (when the immediate offset fits in 12 bits, at least; compressed load/store has a 5-bit unsigned immediate, multiplied by width). Also, SiFive didn't design this - in 2011 there's already "Given the code size and energy savings of a compressed format, we wanted to build in support for a compressed format to the base ISA rather than adding this as an afterthought" in the manual[0], while SiFive was founded on 2015. [0]: https://www2.eecs.berkeley.edu/Pubs/TechRpts/2011/EECS-2011-62.pdf https://www2.eecs.berkeley.edu/Pubs/TechRpts/2011/EECS-2011-...

camel-cdr 2y ago

It's not as black and white as you portray it. Both sides of the argument agree that high-performance implementations are doable and not hindered much buy both, you can watch the debate in the profiles SIG zoom meetings. I think the real dispute was how the opcode space and code density will evolve when more and more extension will need to be added. Will more 32 opcode space and aligned 64 bit instructions but no 16 and no 48 bit instructions in the longterm be a better choice than fewer 32 bit instructions, but 16/48/64 bit instructions? Qualcomm is also currently involved in the Combined Instructions SIG, and proposed a few instructions in that vain: https://docs.google.com/spreadsheets/d/1dQYU7QQ-SnIoXp9vVvVjS6Jz9vGWhwmsdbEOF3JBwUg/edit#gid=0 https://docs.google.com/spreadsheets/d/1dQYU7QQ-SnIoXp9vVvVj.... Notice that these are currently very mild combined instructions, like BEQI, or CLO, which are unlikely to be cracked into uops compared to more complex addressing modes (e.g. apple silicon needs to crack pre/post increment load/stores). BTW, this article is actually about removing Qualcomm specific stuff from android, see: https://lists.riscv.org/g/sig-android/topic/105816077#msg389 https://lists.riscv.org/g/sig-android/topic/105816077#msg389

dzaima 2y ago

RISC-V already has an extension for simplifying address calculations, Zba, required for RVA23, for doing x*2+y, x*4+y, and x*8+y in a single instruction (sh1add/sh2add/sh3add; these don't have compressed variants, so always 4 bytes). Combined with the immediate offset in load/store instructions, that's two instructions (6 or 8 bytes depending on whether the load/store can be compressed) for any x86 mov (when the immediate offset fits in 12 bits, at least; compressed load/store has a 5-bit unsigned immediate, multiplied by width). Also, SiFive didn't design this - in 2011 there's already "Given the code size and energy savings of a compressed format, we wanted to build in support for a compressed format to the base ISA rather than adding this as an afterthought" in the manual[0], while SiFive was founded on 2015. [0]: https://www2.eecs.berkeley.edu/Pubs/TechRpts/2011/EECS-2011-62.pdf https://www2.eecs.berkeley.edu/Pubs/TechRpts/2011/EECS-2011-...