Hacker News

Because the other commenter wasn’t posting the actual answer, I went to find the documentation about checking for integer overflow and it’s right here https://docs.riscv.org/reference/isa/unpriv/rv32.html#2-1-4-...

And what did I find? Yep that code is right from the manual for unsigned integer overflow.

For signed addition if you know one of the signs (eg it’s a compile time constant) the manual says

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

But the general case for signed addition if you need to check for overflow and don’t have knowledge of the signs

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

From what I’ve read most native compiled code doesn’t really check for overflows in optimised builds, but this is more of an issue for JavaScript et al where they may detect the overflow and switch the underlying type? I’m definitely no expert on this.

sitharus 21 hours ago [ - ]

A bit more reading shows there's a three instruction general case version for 32-bit additions on the 64-bit RISC-V ISA. I'm not familiar with RISC-V assembly and they didn't provide an example, but I _think_ it's as easy as this since 64-bit add wouldn't match the 32-bit overflowed add.

  add t0, t1, t2
  addw t3, t1, t2
  bne t0, t3, overflow

userbinator 18 hours ago [ - ]

Contrast with x86:

    add eax, ecx
    jo overflow

rwmj 12 hours ago [ - ]

Neither x86-64 nor RISC-V is implemented by running each single instruction. They both recognize patterns in the code and translate those into micro-ops. On high performance chips like Rivos's (now Meta's) I doubt there'd be any difference in the amount of work done.

Code size is a benefit for x86-64 however - no one is arguing that - but you have to trade that against the difficulty of instruction decoding.