6 ms·

I hope they're able to get this ISA-level feedback to people at RVI

dmitrygr 2y ago
None of this is new. None of it. In fact, bitfield extract is such an obvious oversight that it is my favourite example of how idiotic the RISCV ISA is (#2 is lack of sane addressing modes). Some of the better RISCV designs, in fact, implement a custom instr to do this, eg: BEXTM in Hazard3: https://github.com/Wren6991/Hazard3/blob/stable/doc/hazard3.pdf https://github.com/Wren6991/Hazard3/blob/stable/doc/hazard3....
- renox 2y ago
  Whoa, someone else who doesn't believe that the RISC-V ISA is 'perfect'! I'm curious: how the discussions on the bitfield extract have been going? Because it does really seem like an obvious oversight and something to add as a 'standard extension'. What's your take on 1) unaligned 32bit instructions with the C extension? 2) lack of 'trap on overflow' for arithmetic instructions? MIPS had it..
  - dmitrygr 2y ago
    1. aarch64 does this right. RISCV tries to be too many things at once, and predictably ends up sucking at everything. Fast big cores should just stick to fixed size instrs for faster decode. You always know where instrs start, and every cacheline has an integer number of instrs. microcontroler cores can use compressed intrs, since it matters there, while trying to parallel-codec instrs does not matter there. Trying to have one arch cover it all is idiotic. 2. nobody uses it on mips either, so it is likely of no use.
    - bonzini 2y ago
      Fixed size instructions are not absolutely necessary, but keeping them naturally aligned is just better even if that means using C instructions a bit less often. It's especially messy that 32-bit instructions can span a page.
    - loup-vaillant 2y ago
      > Fast big cores should just stick to fixed size instrs for faster decode. How much faster, though? RISC-V decode is not crazy like x86, you only need to look at the first byte to know how long the instruction is (the first two bits if you limit yourself to 16 and 32-bit instructions, 5 bits if you support 48-bits instructions, 6 bits if you support 64-bits instructions). Which means, the serial part of the decoder is very very small. The bigger complain about variable length instruction is potentially misaligned instructions, which does not play well with cache lines (a single instruction may start in a cache line and end at the next, making hardware a bit more hairy). And there’s an advantage to compressed instructions even on big cores: less pressure on the instruction cache, and correspondingly fewer cache misses. Thus, it’s not clear to me that fixed size instructions is the obvious way to go for big cores.
      - newpavlov 2y ago
        Another argument against the C extension is that it uses a big chunk of the opcode space, which may be better used for other extensions with 32-bit instructions.
        camel-cdr 2y ago
        Are just 32-bit and naturally aligned 64 bit instruction a better path than fewer 32 bit, but 16/48/64 bit instructions? I think it's quite unclear which one is better. 48-bit instructions have a lot of potential imo, they have better code density then naturally aligned 64 bit instructions, and they can encode more that 32-bit. (2/3 to 3/4 of 43-bits of encoding) There are essentially two design philosophies: 1. 32-bit instructions, and 64 bit naturally aligned instructions 2. 16/32/48/64 bit instructions with 16 bit alignment Implementation complexity is debatable, although it seems to somewhat favor options 1: 1: you need to crack instructions into uops, because your 32-bit instructions need to do more complex things 2: you need to find instruction starts, and handle decoding instructions that span across a cache line How big the impact is relative to the entire design is quite unclear. Finding instruction starts means you need to propagate a few bits over your entire decode width, but cracking also requires something similar. Consider that if you can handle 8 uops, then those can come from the first 4 instructions that are crackes into 2 uops each, or from 8 instructions that don't need to be cracked, and everything in between. With cracking, you have more freedom when you want to do it in the pipeline, but you still have to be able to handle it. In the end, both need to decode across cachelines for performance, but one needs to deal with an instruction split across those cache lines. To me this sounds like it might impact verification complexity more than the actual implementation, but I'm not qualified enough to know. If both options are suited for high performance implementations, then it's a question about tradeoffs and ISA evolution.
    - renox 2y ago
      >2. nobody uses it on mips either, so it is likely of no use. Sure but at the time Rust, Zig didn't exist, these two languages have a mode which detects integer overflow..
  - newpavlov 2y ago
    The handling of misaligned loads/stores in RISC-V is also can be considered a disappointing point: https://github.com/riscv/riscv-isa-manual/issues/1611 https://github.com/riscv/riscv-isa-manual/issues/1611 It oozes with preferring convenience of hardware developers and "flexibility" over making practical guarantees needed by software developers. It looks like the MIPS patent on misaligned load/store instructions has played its negative role. The patent expired in 2019, but it seems we are stuck with the current status quo nevertheless.
  - phkahler 2y ago
    IMHO they made a mistake by not allowing immediate data to follow instructions. You could encode 8 bit constants within the opcode, but anything larger should be properly supported with immediate data. As for the C extension, I think that was also inferior because it was added afterward. I'd like to see a re-encoding of the entire ISA in about 10 years once things are really stable.
    - dmitrygr 2y ago
      The main problem with what you’re saying is that none of the lessons learned are new. They were all well-known before this ISA was designed, so if the designers had any intention of learning from the past, they had every opportunity to do so.
- Findecanor 2y ago
  Bitfield-extract is being discussed for a future extension. E.g. Qualcomm is pressing for it to be added. In the meantime, it can be done as two shifts: left to the MSB, and then right filling with zero or sign bits. There is at least one core in development (SpaceMiT X100) that is supposed to be able to fuse those two into a single µop, maybe some that already do. However, I've also seen that one core (XianShan Nanhu) is fusing pairs of RVI instructions into one in the B extension, to be able to run old binaries compiled for CPUs without B faster. Throwing hardware at the problem to avoid a recompile ... feels a bit backwards to me.
camel-cdr 2y ago
The scalar efficiency SIG has already been discussing bitfield insert and extract instructions. We figured out yesterday [1], that the example in the article can already be done in four risc-v instructions, it's just a bit trickier to come up with it: # a0 = rax, a1 = rbx slli t0, a1, 64-8 rori a0, a0, 16 add a0, a0, t0 rori a0, a0, 64-16 [1] https://www.reddit.com/r/RISCV/comments/1f1mnxf/box64_and_riscv_in_2024/ https://www.reddit.com/r/RISCV/comments/1f1mnxf/box64_and_ri...
- bonzini 2y ago
  Nice trick, in fact with 4 instructions it's as efficient as extract/insert and it works for all ADD/SUB/OR/XOR/CMP instructions (not for AND), except if the source is a high-byte register. However it's not really a problem if code generation is not great in this case: compilers in practice will not generate accesses to these registers, and while old 16-bit assembly code has lots of such accesses it's designed to run on processors that ran at 4-20 MHz. Flag computation and conditional jumps is where the big optimization opportunities lie. Box64 uses a multi-pass decoder that computes liveness information for flags and then computes flags one by one. QEMU instead tries to store the original operands and computes flags lazily. Both approaches have advantages and disadvantages...
  - ptitSeb 2y ago
    Actually, Box64 can also store operands for later computation, depending on what comes next...
  - brucehoult 2y ago
    > except if the source is a high-byte register That's just one more instruction, to right-align the AH, BH etc src operand prior to exactly the same instructions as above. And, yes, this being 64 bit code compilers won't be generating such instructions. In fact they started avoiding them as soon as OoO hit in the Pentium Pro, P II, P III etc in the mid 90s because of "partial register update stalls".
- ksco 2y ago
  Author here, we have adopted this approach as a fast path to box64: https://github.com/ptitSeb/box64/pull/1763 https://github.com/ptitSeb/box64/pull/1763, thank you very much!

None of this is new. None of it. In fact, bitfield extract is such an obvious oversight that it is my favourite example of how idiotic the RISCV ISA is (#2 is lack of sane addressing modes). Some of the better RISCV designs, in fact, implement a custom instr to do this, eg: BEXTM in Hazard3: https://github.com/Wren6991/Hazard3/blob/stable/doc/hazard3.pdf https://github.com/Wren6991/Hazard3/blob/stable/doc/hazard3....

renox 2y ago
Whoa, someone else who doesn't believe that the RISC-V ISA is 'perfect'! I'm curious: how the discussions on the bitfield extract have been going? Because it does really seem like an obvious oversight and something to add as a 'standard extension'. What's your take on 1) unaligned 32bit instructions with the C extension? 2) lack of 'trap on overflow' for arithmetic instructions? MIPS had it..
- dmitrygr 2y ago
  1. aarch64 does this right. RISCV tries to be too many things at once, and predictably ends up sucking at everything. Fast big cores should just stick to fixed size instrs for faster decode. You always know where instrs start, and every cacheline has an integer number of instrs. microcontroler cores can use compressed intrs, since it matters there, while trying to parallel-codec instrs does not matter there. Trying to have one arch cover it all is idiotic. 2. nobody uses it on mips either, so it is likely of no use.
  - bonzini 2y ago
    Fixed size instructions are not absolutely necessary, but keeping them naturally aligned is just better even if that means using C instructions a bit less often. It's especially messy that 32-bit instructions can span a page.
  - loup-vaillant 2y ago
    > Fast big cores should just stick to fixed size instrs for faster decode. How much faster, though? RISC-V decode is not crazy like x86, you only need to look at the first byte to know how long the instruction is (the first two bits if you limit yourself to 16 and 32-bit instructions, 5 bits if you support 48-bits instructions, 6 bits if you support 64-bits instructions). Which means, the serial part of the decoder is very very small. The bigger complain about variable length instruction is potentially misaligned instructions, which does not play well with cache lines (a single instruction may start in a cache line and end at the next, making hardware a bit more hairy). And there’s an advantage to compressed instructions even on big cores: less pressure on the instruction cache, and correspondingly fewer cache misses. Thus, it’s not clear to me that fixed size instructions is the obvious way to go for big cores.
    - newpavlov 2y ago
      Another argument against the C extension is that it uses a big chunk of the opcode space, which may be better used for other extensions with 32-bit instructions.
      - camel-cdr 2y ago
        Are just 32-bit and naturally aligned 64 bit instruction a better path than fewer 32 bit, but 16/48/64 bit instructions? I think it's quite unclear which one is better. 48-bit instructions have a lot of potential imo, they have better code density then naturally aligned 64 bit instructions, and they can encode more that 32-bit. (2/3 to 3/4 of 43-bits of encoding) There are essentially two design philosophies: 1. 32-bit instructions, and 64 bit naturally aligned instructions 2. 16/32/48/64 bit instructions with 16 bit alignment Implementation complexity is debatable, although it seems to somewhat favor options 1: 1: you need to crack instructions into uops, because your 32-bit instructions need to do more complex things 2: you need to find instruction starts, and handle decoding instructions that span across a cache line How big the impact is relative to the entire design is quite unclear. Finding instruction starts means you need to propagate a few bits over your entire decode width, but cracking also requires something similar. Consider that if you can handle 8 uops, then those can come from the first 4 instructions that are crackes into 2 uops each, or from 8 instructions that don't need to be cracked, and everything in between. With cracking, you have more freedom when you want to do it in the pipeline, but you still have to be able to handle it. In the end, both need to decode across cachelines for performance, but one needs to deal with an instruction split across those cache lines. To me this sounds like it might impact verification complexity more than the actual implementation, but I'm not qualified enough to know. If both options are suited for high performance implementations, then it's a question about tradeoffs and ISA evolution.
  - renox 2y ago
    >2. nobody uses it on mips either, so it is likely of no use. Sure but at the time Rust, Zig didn't exist, these two languages have a mode which detects integer overflow..
- newpavlov 2y ago
  The handling of misaligned loads/stores in RISC-V is also can be considered a disappointing point: https://github.com/riscv/riscv-isa-manual/issues/1611 https://github.com/riscv/riscv-isa-manual/issues/1611 It oozes with preferring convenience of hardware developers and "flexibility" over making practical guarantees needed by software developers. It looks like the MIPS patent on misaligned load/store instructions has played its negative role. The patent expired in 2019, but it seems we are stuck with the current status quo nevertheless.
- phkahler 2y ago
  IMHO they made a mistake by not allowing immediate data to follow instructions. You could encode 8 bit constants within the opcode, but anything larger should be properly supported with immediate data. As for the C extension, I think that was also inferior because it was added afterward. I'd like to see a re-encoding of the entire ISA in about 10 years once things are really stable.
  - dmitrygr 2y ago
    The main problem with what you’re saying is that none of the lessons learned are new. They were all well-known before this ISA was designed, so if the designers had any intention of learning from the past, they had every opportunity to do so.
Findecanor 2y ago
Bitfield-extract is being discussed for a future extension. E.g. Qualcomm is pressing for it to be added. In the meantime, it can be done as two shifts: left to the MSB, and then right filling with zero or sign bits. There is at least one core in development (SpaceMiT X100) that is supposed to be able to fuse those two into a single µop, maybe some that already do. However, I've also seen that one core (XianShan Nanhu) is fusing pairs of RVI instructions into one in the B extension, to be able to run old binaries compiled for CPUs without B faster. Throwing hardware at the problem to avoid a recompile ... feels a bit backwards to me.

camel-cdr 2y ago

The scalar efficiency SIG has already been discussing bitfield insert and extract instructions. We figured out yesterday [1], that the example in the article can already be done in four risc-v instructions, it's just a bit trickier to come up with it: # a0 = rax, a1 = rbx slli t0, a1, 64-8 rori a0, a0, 16 add a0, a0, t0 rori a0, a0, 64-16 [1] https://www.reddit.com/r/RISCV/comments/1f1mnxf/box64_and_riscv_in_2024/ https://www.reddit.com/r/RISCV/comments/1f1mnxf/box64_and_ri...

bonzini 2y ago
Nice trick, in fact with 4 instructions it's as efficient as extract/insert and it works for all ADD/SUB/OR/XOR/CMP instructions (not for AND), except if the source is a high-byte register. However it's not really a problem if code generation is not great in this case: compilers in practice will not generate accesses to these registers, and while old 16-bit assembly code has lots of such accesses it's designed to run on processors that ran at 4-20 MHz. Flag computation and conditional jumps is where the big optimization opportunities lie. Box64 uses a multi-pass decoder that computes liveness information for flags and then computes flags one by one. QEMU instead tries to store the original operands and computes flags lazily. Both approaches have advantages and disadvantages...
- ptitSeb 2y ago
  Actually, Box64 can also store operands for later computation, depending on what comes next...
- brucehoult 2y ago
  > except if the source is a high-byte register That's just one more instruction, to right-align the AH, BH etc src operand prior to exactly the same instructions as above. And, yes, this being 64 bit code compilers won't be generating such instructions. In fact they started avoiding them as soon as OoO hit in the Pentium Pro, P II, P III etc in the mid 90s because of "partial register update stalls".
ksco 2y ago
Author here, we have adopted this approach as a fast path to box64: https://github.com/ptitSeb/box64/pull/1763 https://github.com/ptitSeb/box64/pull/1763, thank you very much!