Hacker News Reader

Comment by wmil | Hacker News Reader

There's an integer overflow flag that gets set after operations. My x86 books are all boxed up somewhere so I can't look up the details.

View on HN

That still exists though? add rax, rbx/jo overflow_error is how you do overflow checking on x86-64.

That doesn’t work with a lot of arithmetic, so you have to use slower arithmetic in order to use it.

Sure, but that didn't change much between x86 and x86-64. Perhaps it got a little worse because the SIMD instructions aren't overflow check friendly.

As I understand this is about trapping, which makes overflow checking free for non-overflowing operations.

Flag checking, as opposed to trapping, incurs costs on all operations.

INTO would still need to check the flags and you would need to invoke it after every operation that could overflow. You can't configure the integer ALU to raise an interrupt automatically after any overflow.

Is there a reason to not add a new instruction to x86-64 which does interrupt the program on an integer operation overflow so no branching happens in the program? And can this instruction be made just as fast as the unchecked ones?

Maybe is possible and it would be very useful.

I know nothing about micro-architectural implementations, but as far as I can remember, all instructions that can trap (load/stores, divs, etc) take more than one clock cycle. Simple sub/adds usually have 1 cycle latency; there just might not be enough latency budget to fit the trapping machinery.

I guess that the trapping doesn't actually need happen in the critical path (i.e. the results might be available earlier) but this would mean that even ALU instructions cause speculation.

Having a mode that makes all existing arithmetic instructions interrupt sounds plausible, though there must be something I overlooked.

That wouldn't work well for C since signed overflow is undefined, but unsigned overflow is well-defined, with wrapping semantics. Making all existing arithmetic instructions trapping would mean paying trapping costs for well-defined unsigned overflow.

I think this would be a per-thread state which you toggle, defaulting to "off". Then instead of checking and branching after each operation you flip it on/off depending on the type of arithmetic you want. The trick would be to get to the minimal number of toggles and not do the "safe" thing and set it to on/off for each operation.

Generally this sort of global states are considered a misfeature. They are hard to use and impede cpu design (they are particularly bad for OoO). It is better to have per instruction flags.

For exemple while SSE still has an fpu control word, explicit instructions were added for some stuff that historically was handled by the control register (rounding for example).

Reply on news.ycombinator.com