Addressing Criticism of RISC-V Microprocessors

Addressing Criticism of RISC-V Microprocessors
erik-engheim.medium.com

However, I do want to point out that a real issue (especially with legacy code) is the scaled address calculation with 32-bit unsigned values. Thankfully the Zba extension adds a number of instructions that help a lot, but still would require fusion to get complete parity with Arm64

For

    int update(int *base, unsigned index) { return base[index]++; }

    update:
            sh2add.uw  a1,a1,a0
            lw         a0,0(a1)
            addiw      a5,a0,1
            sw         a5,0(a1)
            ret

EDIT: grammar and spacing

One thing ARM and x86 got right that SPARC and POWER got wrong is widely-available machines available at reasonable prices. All the 'being right' in the world won't help if developers need a five-figure hardware budget to port to your platform. VMs don't cut it for bringup.

The fact is that integer operations and floating point are two completely different beasts, so much so that we have different benchmark suites for each.

Integer operations are critically latency sensitive and bagging on extra semantics doesn't come for free and for most code this would be a tax. The "overflow bit" represents an implicit result that would have to be threaded around (I'm assuming that you aren't asking for exceptions which literally nobody wants). For FP we do that, but the cost and latency of FP ops is already high so it doesn't hurt quite as much.

The RISC-V spec [1] (which I assume you have seen) already discusses all these trade offs:

"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. Overflow checking for unsigned addition requires only a single additional branch instruction after the addition:

    add t0, t1, t2
    bltu t0, t1, overflow

     addi t0, t1, +imm
     blt t0, t1, overflow

     add t0, t1, t2
     slti t3, t2, 0
     slt t4, t0, t1
     bne t3, t4, overflow

I do think that it might have been worth adding an single instruction version for the last one (excluding the branch), but I'm not aware of it getting accepted.

[1] https://github.com/riscv/riscv-isa-manual