Comment by brucehoult

2 days 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.

3 comments

brucehoult

adrian_b 2 days 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 13 hours 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 3 hours 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.