I happen to be implementing my own JavaScript JIT compiler and I can tell you that SpiderMonkey, V8 and my compiler all perform a lot of overflow checks. This is because in JavaScript, all numbers are doubles, but JITs typically try to represent them as integers where possible, because integer operations have lower latency.
Scheme and Common Lisp also rely on overflow checks to optimize small integers as "fixnums" instead of always using arbitrary precision arithmetic. Not having hardware support for overflow checks would complicate the implementation of many dynamic languages, and reduce their performance significantly.
Not sure what this guy was thinking. It can't be that hard to implement some overflow flag you can branch on, I mean, adders basically produces that information for free, don't they? Seems like a poor design choice.
Hmm; carry is free, not sure about overflow.
But more generally, it's an extra output, for what would otherwise be one-output operations. Put it this way - if a lot of javascript operations could modify a piece of global state, that would be trivial on a trivial interpreter, but I bet it would add a lot of complexity to your JIT. Same goes for CPUs - no problem for simple implementations, but it would add complexity to an out-of-order or other clever microarchitecture.
Scheme and Common Lisp also rely on overflow checks to optimize small integers as "fixnums" instead of always using arbitrary precision arithmetic. Not having hardware support for overflow checks would complicate the implementation of many dynamic languages, and reduce their performance significantly.
Not sure what this guy was thinking. It can't be that hard to implement some overflow flag you can branch on, I mean, adders basically produces that information for free, don't they? Seems like a poor design choice.