3 ms·

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 a

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.

tialaramex 6mo ago
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 6mo ago
  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.
kps 6mo ago
> It isn't because no ISA implements add like that MIPS does (did?). And VAX, IBM/360, ....
- fulafel 6mo ago
  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.
codedokode 6mo ago
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 6mo ago
  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.

tialaramex 6mo ago

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 6mo ago
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.

kps 6mo ago

> It isn't because no ISA implements add like that MIPS does (did?). And VAX, IBM/360, ....

fulafel 6mo ago
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.

codedokode 6mo ago

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 6mo ago
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.