4 ms·
I prefer branching. Interrupt is inconvenient especially if you mean not panic and die but do some recovery. Conditional jump after arithmetic operation could b
by 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 agoYour comment actually swayed my opinion. If you are to do anything useful after the overflow, you'll need branching...
- R0b0t1 6y agoNo, 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.