[IshKebab]

It isn't because no ISA implements add like that, so there's always performance on the table if you check every time, and people would probably endlessly moan about how Rust is 20% slower than C on this add-heavy microbenchmark.

That said you can enable overflow checks in Rust's release mode. It's literally two lines:

  [profile.release]
  overflow-checks = true

I wonder if it would make sense for ISAs to have trapping versions of add and subtract. RISC-V's justification for not doing that is that it's only a couple more instructions to check afterwards. It would be interesting to see the performance difference of `overflow-check = true` on high performance RISC-V chips once they are available.

[codedokode]

I think it is 3 extra instructions on RISC-V if you add signed numbers. So 1 addition (the most popular operation) turns into 4 instructions. What are those people thinking? I generally like RISC-V but this part in my opinion, is wrong. They should just have added "overflow enabled" bit to the add instruction.

[IshKebab]

In fairness I don't think it's quite as much of a no brainer as you'd think. Firstly, when RISC-V was developed Rust was still pre-1.0. People didn't think it would amount to anything. So most high performance code was C/C++ which doesn't have checked arithmetic.

Second, it's easy to say "trap on overflow" but traps are super annoying. You really ideally would want to avoid leaving user mode. As soon as you trap to the OS you're now dealing with signals which are pretty much the worst thing in the world. The 4 instruction case at least lets you just branch to other code.

So you ideally want an "add or branch" instruction, but there isn't enough space in the opcodes for that. The fallback is flags, which also massively suck. I don't know if anyone has a great solution to this problem.

[kps]

> It isn't because no ISA implements add like that

MIPS does (did?). And VAX, IBM/360, ....

[fulafel]

overflow check insns also in 6502 (bvs), x86 (into), m68k (trapv) - the gp was after something that wouldn't need to be checked every time, if interpreted as "no extra instructions" then that's a tall order. But the checks are practically free in modern big core CPUs since we have so much spare capacity in issue width in 99% of workloads.

[tialaramex]

It does seem like "What if we offer checked integer arithmetic operations?" is a cheaper experiment than CHERI's "What if we mechanically reify extent based provenance"?"

[IshKebab]

But also way less impactful. It would solve maybe 20% of serious security vulnerabilities whereas CHERI solves like 60% at least. More if you use its strong compartmentalisation capabilities (heh).

That said, CHERI is super complicated. Checked integer arithmetic operations would be way simpler.