3 ms·

It's also IMHO a failure of RISC-V. "We did not include special instruction set support for overflow checks on integer arithmetic operations in the base instruc

by brohee 6y ago

It's also IMHO a failure of RISC-V. "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" Cheaply is not freely.

dathinab 6y ago
The question is how much more expensive then a overflow checked add, which is mostly likely not as cheap as a non checked add. I mean in the end both do a non checked add and then branch on the carry. One does it implicitly and branches to an interrupt and one does it explicitly and branches however you like it. (Slightly) Increased chip complexity should be included in the choice, too. I guess the main difference would/could be if used with some form of branch prediction.
ordu 6y ago
I prefer branching. Interrupt is inconvenient especially if you mean not panic and die but do some recovery. Conditional jump after arithmetic operation could be as cheap as one instruction, branch prediction could make this instruction to cost almost nothing in terms of execution times (at least if overflows are a rare thing), and you could point this branch anywhere you like, so you could process overflow and try to recover from error without going outside of a current stack frame. It could be ugly in a high-level languages though. Instead of (a+b)*c you might get something like a.checked_add(b) .map(|x| x.checked_mul(c)) .flatten() .unwrap_or_else(|| do_something_to_recover(a, b, c)); At the same time there is nothing to forbid a syntax like: ((a⊕b)⊙c).flatten().unwrap_or_else(|| do_something to recover(a, b, c)); Just people do not like to use unicode in programming languages.
- brohee 6y ago
  Your comment actually swayed my opinion. If you are to do anything useful after the overflow, you'll need branching...
  - R0b0t1 6y ago
    No, sometimes overflow is so rare the trap saves you time in the majority case. Also sometimes panicking on hardware trap is the useful thing. If we had more ALU variety these discussions wouldn't pop up. Saturating arithmetic, bounded arithmetic, etc are all useful and safer by default in most cases.

by brohee 6y ago

dathinab 6y ago

The question is how much more expensive then a overflow checked add, which is mostly likely not as cheap as a non checked add. I mean in the end both do a non checked add and then branch on the carry. One does it implicitly and branches to an interrupt and one does it explicitly and branches however you like it. (Slightly) Increased chip complexity should be included in the choice, too. I guess the main difference would/could be if used with some form of branch prediction.

ordu 6y ago

I prefer branching. Interrupt is inconvenient especially if you mean not panic and die but do some recovery. Conditional jump after arithmetic operation could be as cheap as one instruction, branch prediction could make this instruction to cost almost nothing in terms of execution times (at least if overflows are a rare thing), and you could point this branch anywhere you like, so you could process overflow and try to recover from error without going outside of a current stack frame. It could be ugly in a high-level languages though. Instead of (a+b)*c you might get something like a.checked_add(b) .map(|x| x.checked_mul(c)) .flatten() .unwrap_or_else(|| do_something_to_recover(a, b, c)); At the same time there is nothing to forbid a syntax like: ((a⊕b)⊙c).flatten().unwrap_or_else(|| do_something to recover(a, b, c)); Just people do not like to use unicode in programming languages.

brohee 6y ago
Your comment actually swayed my opinion. If you are to do anything useful after the overflow, you'll need branching...
- R0b0t1 6y ago
  No, sometimes overflow is so rare the trap saves you time in the majority case. Also sometimes panicking on hardware trap is the useful thing. If we had more ALU variety these discussions wouldn't pop up. Saturating arithmetic, bounded arithmetic, etc are all useful and safer by default in most cases.