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.
replyIn 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.
replySecond, 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.
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"?"
replyBut 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).
replyThat said, CHERI is super complicated. Checked integer arithmetic operations would be way simpler.
> It isn't because no ISA implements add like that
replyMIPS does (did?). And VAX, IBM/360, ....