4 ms·
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.
by wmil 6y ago
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.
- gsg 6y agoThat still exists though? add rax, rbx/jo overflow_error is how you do overflow checking on x86-64.
- chrisseaton 6y agoThat doesn’t work with a lot of arithmetic, so you have to use slower arithmetic in order to use it.
- gsg 6y agoSure, 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.
- praptak 6y agoAs 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.
- gpderetta 6y agoINTO 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.
- zeotroph 6y agoIs 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?
- deleted 6y ago[deleted]
- xpressvideoz 6y agoHaving a mode that makes all existing arithmetic instructions interrupt sounds plausible, though there must be something I overlooked.
- tom_mellior 6y agoThat 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.
- zeotroph 6y agoI 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.
- gpderetta 6y agoGenerally 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).
- gpderetta 6y agoMaybe 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.
- deleted 6y ago[deleted]