31–40 of 198 posts
Earlier quoted context omitted.
I wasn’t aware of this - which instruction do you mean?
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.
Flag checking, as opposed to trapping, incurs costs on all operations.
The problem with integer overflow, in the general context of UB, isn't that it's expensive to trap. The problem is that the C (and C++) specs insist on overflow being undefined behavior. Then compilers insist on abusing the UB as meaning that they get to do whatever they want. This particular case is only partially the compiler's fault, as the various specs should not be defining well specified behavior as being unde…
It seems suspicious to me that clang is so much cheaper than gcc.
It's worth mentioning that x86 CPUs had a single instruction overflow test that would raise a hardware interrupt in response to an integer overflow. This allowed for extremely low cost integer overflow tests. Unfortunately, this capability was deleted from x86-64 and we're now stuck with either accepting the risks of integer overflows or suffering a performance hit to test for them by using multiple instructions. Ano…
I wasn’t aware of this - which instruction do you mean?
It signals int 0x04 if the instruction is executed while the overflow flag is set due to a prior signed arithmetic operation wrapping.
It seems I misspoke somewhat; there is somewhat equivalent functionality in x64 in the JO instructions, but they're six bytes rather than one and the extra size could have cache and/or memory bandwidth impacts under demanding circumstances.
From GCC documentation, >The compiler will attempt to use hardware instructions to implement these built-in functions where possible, like conditional jump on overflow after addition, conditional jump on carry etc. I suspect something's not exactly right with compiler flags. Then again, how much of your program is integer arithmetic? 12x slowdown on 0.1% is 1.2%.
What I find annoying is we go back and forth over this because the insistence on clinging to the one true holy int type as on Gods Blessed Machine the PDP 11. Instead of implementing proper variable types like you have with Ada. Seriously considering code can compiled for on 16, 32, and 64 bit machines 'int' is dodgy as hell.
Earlier quoted context omitted.
I wasn’t aware of this - which instruction do you mean?
I think the GP was probably thinking of INTO(0xCE). https://en.wikipedia.org/wiki/INT_(x86_instruction)#INTO The bounds-checking was MPX, I think. > Another extremely useful instruction deleted from x86-64 tested if an array access was in bounds. https://en.wikipedia.org/wiki/Intel_MPX#Extensions
Earlier quoted context omitted.
I wasn’t aware of this - which instruction do you mean?
INTO. It signals int 0x04 if the instruction is executed while the overflow flag is set due to a prior signed arithmetic operation wrapping. It seems I misspoke somewhat; there is somewhat equivalent functionality in x64 in the JO instructions, but they're six bytes rather than one and the extra size could have cache and/or memory bandwidth impacts under demanding circumstances.
Earlier quoted context omitted.
I wasn’t aware of this - which instruction do you mean?
INTO. It signals int 0x04 if the instruction is executed while the overflow flag is set due to a prior signed arithmetic operation wrapping. It seems I misspoke somewhat; there is somewhat equivalent functionality in x64 in the JO instructions, but they're six bytes rather than one and the extra size could have cache and/or memory bandwidth impacts under demanding circumstances.
Earlier quoted context omitted.
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.
That still exists though? add rax, rbx/jo overflow_error is how you do overflow checking on x86-64.