5 ms·

RISC-V is copying wrong decisions made tens years ago. Against any common sense it doesn't trap on overflow on arithmetic operations, and silently wraps number

RISC-V is copying wrong decisions made tens years ago. Against any common sense it doesn't trap on overflow on arithmetic operations, and silently wraps number over, producing incorrect result. Furthermore, it does not provide an overflow flag (or any alternative) so it is difficult to make addition of 256-bit numbers for example.

wbl 3y ago
It doesn't trap because trapping means you need to track the possibility of a branch at every single arithmetic operation. It doesn't have a flag so flag renaming isn't needed: you can get the overflow from a CMP instruction and macroop fusion should just work.
- codedokode 3y ago
  > you need to track the possibility of a branch at every single arithmetic operation Every memory access can cause a trap, but CPUs seem to have no problem about it. The branch is very unlikely and can always be predicted as "not taken".
  - twbarr 3y ago
    Hell, with non-maskable interrupts, any instruction can cause a trap!
    - meithecatte 3y ago
      Not even that - instruction fetch can cause a page fault. When an NMI happens,the CPU still has the choice of when to service it. If it needs to flush the pipeline, it might as well retire the instructions up to the first store.
  - hajile 3y ago
    Managing memory coherency is probably the single hardest part to design in any given CPU. Why add even more hard things (especially if they can interact and add even more complexity on top)? Get rid of what complexity you can then deal with the rest that you must have.
    - Dylan16807 3y ago
      Coherency is very hard but it's not what causes traps from accessing memory. That part is a relatively simple permission check.
snvzz 3y ago
I love how each and every criticism on RISC-V's decisions ignores the rationale behind them. Yes, that idea was evaluated, weighted and discarded as harmful, and the details are referenced in the spec itself.
- codedokode 3y ago
  I tried searching the spec [1] for "overflow" and here is what it says at page 17: > We did not include special instruction-set support for overflow checks on integer arithmetic operations in the base instruction set, as many overflow checks can be cheaply implemented using RISC-V branches. > For general signed addition, three additional instructions after the addition are required Is this "cheap", replacing 1 instruction with four? According to some old mainframe era research (cannot find link now), addition is one of the most often used instructions and they suggest that we should replace each instruction with four? Their "rationale" is not rational at all. It doesn't make sense. Overflow check should be free (no additional instructions required), otherwise we will see the same story we have seen for last 50 years: compiler writers do not want to implement checks because they are expensive; language designers do not want to use proper arithmetic because it is expensive. And CPU designers do not want to implement traps because no language needs them. As a result, there will be errors and vulnerabilities. A vicious circle. What also surprises me is that they added fused add-multiply instruction which can easily be replaced by 2 separate instructions, is not really needed in most applications (like a web browser), and is difficult to implement (if I am not mistaken, you need to read 3 registers instead of 2, which might require additional ports in register file only for this useless instruction). [1] https://github.com/riscv/riscv-isa-manual/releases/download/Ratified-IMAFDQC/riscv-spec-20191213.pdf https://github.com/riscv/riscv-isa-manual/releases/download/...
  - brucehoult 3y ago
    So you are criticising RISC-V not compared to its actual x86 and Arm competition -- where overflow checking is also not free and is seldom used -- but against some imaginary ideal CPU that doesn't exist or no one uses because it's so slow.

wbl 3y ago

It doesn't trap because trapping means you need to track the possibility of a branch at every single arithmetic operation. It doesn't have a flag so flag renaming isn't needed: you can get the overflow from a CMP instruction and macroop fusion should just work.

codedokode 3y ago
> you need to track the possibility of a branch at every single arithmetic operation Every memory access can cause a trap, but CPUs seem to have no problem about it. The branch is very unlikely and can always be predicted as "not taken".
- twbarr 3y ago
  Hell, with non-maskable interrupts, any instruction can cause a trap!
  - meithecatte 3y ago
    Not even that - instruction fetch can cause a page fault. When an NMI happens,the CPU still has the choice of when to service it. If it needs to flush the pipeline, it might as well retire the instructions up to the first store.
- hajile 3y ago
  Managing memory coherency is probably the single hardest part to design in any given CPU. Why add even more hard things (especially if they can interact and add even more complexity on top)? Get rid of what complexity you can then deal with the rest that you must have.
  - Dylan16807 3y ago
    Coherency is very hard but it's not what causes traps from accessing memory. That part is a relatively simple permission check.

snvzz 3y ago

I love how each and every criticism on RISC-V's decisions ignores the rationale behind them. Yes, that idea was evaluated, weighted and discarded as harmful, and the details are referenced in the spec itself.

codedokode 3y ago
I tried searching the spec [1] for "overflow" and here is what it says at page 17: > We did not include special instruction-set support for overflow checks on integer arithmetic operations in the base instruction set, as many overflow checks can be cheaply implemented using RISC-V branches. > For general signed addition, three additional instructions after the addition are required Is this "cheap", replacing 1 instruction with four? According to some old mainframe era research (cannot find link now), addition is one of the most often used instructions and they suggest that we should replace each instruction with four? Their "rationale" is not rational at all. It doesn't make sense. Overflow check should be free (no additional instructions required), otherwise we will see the same story we have seen for last 50 years: compiler writers do not want to implement checks because they are expensive; language designers do not want to use proper arithmetic because it is expensive. And CPU designers do not want to implement traps because no language needs them. As a result, there will be errors and vulnerabilities. A vicious circle. What also surprises me is that they added fused add-multiply instruction which can easily be replaced by 2 separate instructions, is not really needed in most applications (like a web browser), and is difficult to implement (if I am not mistaken, you need to read 3 registers instead of 2, which might require additional ports in register file only for this useless instruction). [1] https://github.com/riscv/riscv-isa-manual/releases/download/Ratified-IMAFDQC/riscv-spec-20191213.pdf https://github.com/riscv/riscv-isa-manual/releases/download/...
- brucehoult 3y ago
  So you are criticising RISC-V not compared to its actual x86 and Arm competition -- where overflow checking is also not free and is seldom used -- but against some imaginary ideal CPU that doesn't exist or no one uses because it's so slow.