5 ms·

The ISA not mattering I think isn't as true when you account cost e.g. in a huge OOO cpu all the fusions and so on are afaict fairly doable but if you are on a

by mhh__ 2mo ago

The ISA not mattering I think isn't as true when you account cost e.g. in a huge OOO cpu all the fusions and so on are afaict fairly doable but if you are on a cheaper / worse CPU all those extra bytes in the instruction stream do add up.

wren6991 2mo ago
The RISC-V fusion arguments from back in ~2018 didn't really pan out. A lot of those fusion opportunities are just instructions now. slli + add? Zba (sh*add). slli + srli? Zbb (zext.*). slli + srai? Believe it or not, also Zbb (sext.*). Look at that pair of RVC instructions you used instead of a single 32-bit opcode. They are: * Taking up valuable compressed instruction space; each compressed codepoint has an opportunity cost of 64k uncompressed ones. * Limited in which registers they can use (usually x8..x15). * Often clobber their input operand instead of giving a free move. Also consider that the frequency data that drove the RVC compression decisions was driven by the lack of architecturally fused instructions like sh*add, so any arguments you derive from that data are circular. An instruction can be a good uarch fusion target because it's compressed, and a good compression target because you didn't fuse it in the architecture. I think designing for uarch fusion in your ISA is coming at it from the wrong end. Fusion is something uarch designers do to make up for shortcomings in the ISA.
- brucehoult 2mo ago
  And all modern high performance Arm and x86 cores do more fusion than RISC-V cores that are currently on the market. Intel has being fusing `CMP` and `Bcc` since Core 2 and AMD since Zen 1. This is - already one instruction in RISC-V - an *extremely* common pattern, often occurring once every 5 or 6 instructions.
  - adrian_b 2mo ago
    The combined comparison-branch instructions of RISC-V are its only good feature in terms of instruction encoding design. This allows a significant code size reduction in comparison with ARM Aarch64, but unfortunately for RISC-V this advantage is frequently not enough to compensate its other defects, especially when reliable code is desired, i.e. where overflow detection is necessary. Despite that from this point of view ARM Aarch64 is weaker, that is not an intrinsic problem. Aarch64 has an unused block of encodings inside the block used for branch instructions. I have verified that in the currently unused block it is possible to encode not only compare-and-branch instructions covering all the conditions that exist in the RISC-V ISA, but also additional conditions that are missing in RISC-V, where their absence is a problem, like testing for overflow. I do not know why nobody at Arm had thought to make this extension yet, but it would be very easy to eliminate the only advantage that RISC-V has over Aarch64.
    - zephen 2mo ago
      > I do not know why nobody at Arm had thought to make this extension yet, but it would be very easy to eliminate the only advantage that RISC-V has over Aarch64. Nope. Again, the primary advantage that RISC-V has over Aarch64 is that it is the agreed-upon open specification.
      - brucehoult 2mo ago
        Also I haven't looked closely but I don't know if you could find space to fit it in the remaining Aarch64 encoding space. The existing a64 conditional branch instructions use a 19 bit field to hold the offset. Add two registers to compare (10 bits) and 3 bits to choose between EQ, NE, LT, LTU, GE, GEU and you're already at 32 bits before having an "opcode" field to choose "RISC-V style conditional branch". Of course you could reduce the branch offset size down to RISC-V's ±4k which only needs 11 bits when you only have 4 byte instructions, but that's still a 24 bit chunk of unused opcode space to find. Oh .. looks like 0b10xx is still completely unused. We could grab maybe 1/4 of it So could do ... [31:28] (4 bits): 0b1000 (Fixed primary opcode .. or 0b1001, 0b1010, 0b1011) [27:23] (5 bits): Rs1 [22:18] (5 bits): Rs2 [17:15] (3 bits): Cond (EQ, NE, LT, GE, LTU, GEU, + possible 2 more) [14:4] (11 bits): Offset (Signed ±4k PC-relative offset) [3:0] (4 bits): 0b0000 (Fixed minor opcode/extension identifier) One problem here is this doesn't allow both 32 bit and 64 bit compares. And also the Rs1 and Rs2 are not in the usual places. Maybe... [31:28] (4 bits): 0b1000 (Fixed primary opcode) [27:21] (7 bits): Offset[12:6] [20:16] (5 bits): Rm [15:13] (3 bits): Cond (EQ, NE, LT, GE, LTU, GEU, etc) [12:10] (3 bits): Offset[5:3] [9:5] (5 bits): Rn [4:2] (3 bits): Offset[2:0] [1] (1 bit): sf (Size flag: 0 = 32-bit compare, 1 = 64-bit compare) [0] (1 bit): 0b0 (Fixed) I think this fits other instruction formats better .. and gives a ±16k branch range. Some ::coff:: would criticise the split up offset field. Not RISC-V fans of course. And this puts sf in a non-standard place. Some more playing around is needed .. over to you Arm.
- torginus 2mo ago
  Sorry, haven't been following along, but sounds to me that the argument was a valid one seeing how it made the designers add new instructions. Not sure if there's an impact caused by the late addition as opposed to always having them, but considering this is a fairly core thing what a program does, not sure what degree of fragmentation this causes on the level of compilers and hardware. x86 effectively killed innovation in the SIMD space by making instruction set support so fragmented, that people had to target the decade-old lowest denominator.
  - wren6991 2mo ago
    The arguments were against ISA-level fusion, since they can be fused in the uarch. See for example: https://www2.eecs.berkeley.edu/Pubs/TechRpts/2016/Archive/EECS-2016-130.pdf https://www2.eecs.berkeley.edu/Pubs/TechRpts/2016/Archive/EE...
  - janwas 2mo ago
    Not seeing this at all. We routinely and easily target SSE4, AVX2, AVX-512 (in four variants) using the same application code in one binary. Frankly, this seems better to me than four separate RISC-V matmul extensions.
brucehoult 2mo ago
Performance is subject to debate and quality of implementation and whether such implementations will ever be financed and made ... But *code size* is a demonstrable fact. RISC-V has by far the most compact code of any popular 64 bit ISA, and that was true even of RV64GC. The gap has only widened with RVA23. Just load up your favourite OS (e.g. Ubuntu 26.04) for various ISAs in Docker and compare the `text` size of various binaries, individually or in aggregate. In 32 bit ARMv7-M / ARMv7-A had a small code size lead over RV32IMAC, but this is reversed in modern RISC-V e.g. if you look at RISC-V Hazard3 vs Arm Cortex-M33 in the RP2350 (Raspberry Pi Pico 2) where you can trivially change one option setting in your project and recompile and test. The only exception is that the M33 has a single-precision FPU, which neither the Hazard3 nor the Cortex-M0+ in the RP2040 have.
- dmitrygr 2mo ago
  > RISC-V has by far the most compact code of any popular 64 bit ISA, Forgot to say “RISC”. Cause else: amd64
  - brucehoult 2mo ago
    No, RISC-V code is much more compact than Amd64. This is easily demonstrated on any real application, such as those in your favourite Linux distribution.
- adrian_b 2mo ago
  That is false. All the claims of the RISC-V fans that I have seen in the past compared the compressed variant of RISC-V with the uncompressed variants of the other ISAs. Most other ISAs, like ARM, POWER and MIPS, also have compressed variants and if RISC-V were compared with those, it would lose. Moreover, if you use safe compilation options with RISC-V, the code size explodes in comparison with any other ISA, because I am not aware of any other ISA introduced after 1974 that lacks hardware overflow detection, which multiplies by 3 or more the number of arithmetic instructions required for any computation. This is a new claim that I see now, that RISC-V can be more compact than Cortex-M33 (i.e. where both use a compressed encoding), which I find unbelievable, because if I assembly by hand almost any function that is not too simple I can make it shorter on Cortex-M33 than on RISC-V and I doubt that the current compilers are so bad that they generate much worse code. RISC-V is shorter on any code that has a lot of branches and negligible computations, but for anything more complex, with many computations and complex data structures, it loses.

by mhh__ 2mo ago

wren6991 2mo ago

The RISC-V fusion arguments from back in ~2018 didn't really pan out. A lot of those fusion opportunities are just instructions now. slli + add? Zba (sh*add). slli + srli? Zbb (zext.*). slli + srai? Believe it or not, also Zbb (sext.*). Look at that pair of RVC instructions you used instead of a single 32-bit opcode. They are: * Taking up valuable compressed instruction space; each compressed codepoint has an opportunity cost of 64k uncompressed ones. * Limited in which registers they can use (usually x8..x15). * Often clobber their input operand instead of giving a free move. Also consider that the frequency data that drove the RVC compression decisions was driven by the lack of architecturally fused instructions like sh*add, so any arguments you derive from that data are circular. An instruction can be a good uarch fusion target because it's compressed, and a good compression target because you didn't fuse it in the architecture. I think designing for uarch fusion in your ISA is coming at it from the wrong end. Fusion is something uarch designers do to make up for shortcomings in the ISA.

brucehoult 2mo ago
And all modern high performance Arm and x86 cores do more fusion than RISC-V cores that are currently on the market. Intel has being fusing `CMP` and `Bcc` since Core 2 and AMD since Zen 1. This is - already one instruction in RISC-V - an *extremely* common pattern, often occurring once every 5 or 6 instructions.
- adrian_b 2mo ago
  The combined comparison-branch instructions of RISC-V are its only good feature in terms of instruction encoding design. This allows a significant code size reduction in comparison with ARM Aarch64, but unfortunately for RISC-V this advantage is frequently not enough to compensate its other defects, especially when reliable code is desired, i.e. where overflow detection is necessary. Despite that from this point of view ARM Aarch64 is weaker, that is not an intrinsic problem. Aarch64 has an unused block of encodings inside the block used for branch instructions. I have verified that in the currently unused block it is possible to encode not only compare-and-branch instructions covering all the conditions that exist in the RISC-V ISA, but also additional conditions that are missing in RISC-V, where their absence is a problem, like testing for overflow. I do not know why nobody at Arm had thought to make this extension yet, but it would be very easy to eliminate the only advantage that RISC-V has over Aarch64.
  - zephen 2mo ago
    > I do not know why nobody at Arm had thought to make this extension yet, but it would be very easy to eliminate the only advantage that RISC-V has over Aarch64. Nope. Again, the primary advantage that RISC-V has over Aarch64 is that it is the agreed-upon open specification.
    - brucehoult 2mo ago
      Also I haven't looked closely but I don't know if you could find space to fit it in the remaining Aarch64 encoding space. The existing a64 conditional branch instructions use a 19 bit field to hold the offset. Add two registers to compare (10 bits) and 3 bits to choose between EQ, NE, LT, LTU, GE, GEU and you're already at 32 bits before having an "opcode" field to choose "RISC-V style conditional branch". Of course you could reduce the branch offset size down to RISC-V's ±4k which only needs 11 bits when you only have 4 byte instructions, but that's still a 24 bit chunk of unused opcode space to find. Oh .. looks like 0b10xx is still completely unused. We could grab maybe 1/4 of it So could do ... [31:28] (4 bits): 0b1000 (Fixed primary opcode .. or 0b1001, 0b1010, 0b1011) [27:23] (5 bits): Rs1 [22:18] (5 bits): Rs2 [17:15] (3 bits): Cond (EQ, NE, LT, GE, LTU, GEU, + possible 2 more) [14:4] (11 bits): Offset (Signed ±4k PC-relative offset) [3:0] (4 bits): 0b0000 (Fixed minor opcode/extension identifier) One problem here is this doesn't allow both 32 bit and 64 bit compares. And also the Rs1 and Rs2 are not in the usual places. Maybe... [31:28] (4 bits): 0b1000 (Fixed primary opcode) [27:21] (7 bits): Offset[12:6] [20:16] (5 bits): Rm [15:13] (3 bits): Cond (EQ, NE, LT, GE, LTU, GEU, etc) [12:10] (3 bits): Offset[5:3] [9:5] (5 bits): Rn [4:2] (3 bits): Offset[2:0] [1] (1 bit): sf (Size flag: 0 = 32-bit compare, 1 = 64-bit compare) [0] (1 bit): 0b0 (Fixed) I think this fits other instruction formats better .. and gives a ±16k branch range. Some ::coff:: would criticise the split up offset field. Not RISC-V fans of course. And this puts sf in a non-standard place. Some more playing around is needed .. over to you Arm.
torginus 2mo ago
Sorry, haven't been following along, but sounds to me that the argument was a valid one seeing how it made the designers add new instructions. Not sure if there's an impact caused by the late addition as opposed to always having them, but considering this is a fairly core thing what a program does, not sure what degree of fragmentation this causes on the level of compilers and hardware. x86 effectively killed innovation in the SIMD space by making instruction set support so fragmented, that people had to target the decade-old lowest denominator.
- wren6991 2mo ago
  The arguments were against ISA-level fusion, since they can be fused in the uarch. See for example: https://www2.eecs.berkeley.edu/Pubs/TechRpts/2016/Archive/EECS-2016-130.pdf https://www2.eecs.berkeley.edu/Pubs/TechRpts/2016/Archive/EE...
- janwas 2mo ago
  Not seeing this at all. We routinely and easily target SSE4, AVX2, AVX-512 (in four variants) using the same application code in one binary. Frankly, this seems better to me than four separate RISC-V matmul extensions.

brucehoult 2mo ago

Performance is subject to debate and quality of implementation and whether such implementations will ever be financed and made ... But *code size* is a demonstrable fact. RISC-V has by far the most compact code of any popular 64 bit ISA, and that was true even of RV64GC. The gap has only widened with RVA23. Just load up your favourite OS (e.g. Ubuntu 26.04) for various ISAs in Docker and compare the `text` size of various binaries, individually or in aggregate. In 32 bit ARMv7-M / ARMv7-A had a small code size lead over RV32IMAC, but this is reversed in modern RISC-V e.g. if you look at RISC-V Hazard3 vs Arm Cortex-M33 in the RP2350 (Raspberry Pi Pico 2) where you can trivially change one option setting in your project and recompile and test. The only exception is that the M33 has a single-precision FPU, which neither the Hazard3 nor the Cortex-M0+ in the RP2040 have.

dmitrygr 2mo ago
> RISC-V has by far the most compact code of any popular 64 bit ISA, Forgot to say “RISC”. Cause else: amd64
- brucehoult 2mo ago
  No, RISC-V code is much more compact than Amd64. This is easily demonstrated on any real application, such as those in your favourite Linux distribution.
adrian_b 2mo ago
That is false. All the claims of the RISC-V fans that I have seen in the past compared the compressed variant of RISC-V with the uncompressed variants of the other ISAs. Most other ISAs, like ARM, POWER and MIPS, also have compressed variants and if RISC-V were compared with those, it would lose. Moreover, if you use safe compilation options with RISC-V, the code size explodes in comparison with any other ISA, because I am not aware of any other ISA introduced after 1974 that lacks hardware overflow detection, which multiplies by 3 or more the number of arithmetic instructions required for any computation. This is a new claim that I see now, that RISC-V can be more compact than Cortex-M33 (i.e. where both use a compressed encoding), which I find unbelievable, because if I assembly by hand almost any function that is not too simple I can make it shorter on Cortex-M33 than on RISC-V and I doubt that the current compilers are so bad that they generate much worse code. RISC-V is shorter on any code that has a lot of branches and negligible computations, but for anything more complex, with many computations and complex data structures, it loses.