3 ms·

It would be nice to have C/C++ operators/types that failed on overflow/underflow. The sad part is it's available on all processors in the status register. Just

It would be nice to have C/C++ operators/types that failed on overflow/underflow. The sad part is it's available on all processors in the status register. Just no one has brought it up to the higher level language level. If you could declare hard unsigned int x=0; then things like a.size() - 1 could abort() loudly instead of silently doing something that's probably wrong and masking errors later on.

pcwalton 12y ago
Rust does have those types, but they aren't free: overflow checking has a significant performance cost even when fully optimized. Because of the performance cost, a lot of code doesn't use the overflow-checking types. I think what we really need is for the hardware manufacturers to help us out here.
- StefanKarpinski 12y ago
  Agreed – hardware assistance would be a huge boon.
  - mkup 12y ago
    BOUND instruction on x86 architecture exists for time immemorial, but not widely used and may be slow in modern microcode (like AAM/AAD and other stuff of handwritten assembly era, never emitted by compilers).
- __david__ 12y ago
  > …overflow checking has a significant performance cost even when fully optimized. That surprises me—I would have thought a quick bit-test on the status register and conditional jump wouldn't be all that bad. > I think what we really need is for the hardware manufacturers to help us out here. Are you thinking something like a software interrupt on integer overflow?
  - dbaupp 12y ago
    There's the secondary effects of missed optimisations too: if every operation is checked for overflow, there's much less scope for reordering/collapsing/vectorising operations, (this is also especially important in tight loops where the core loop can easily be less than 20 instructions, so 2 extra is significant).
    - ufo 12y ago
      > if every operation is checked for overflow, there's much less scope for reordering/collapsing/vectorising operations Lets pretend that instead of "put a conditional jump after every operation", we try to model things as "pretend all integers are infinite precision, blow up if overflow happens at some point". So for example, we would be OK with rewriting int x = MAX_INT int y = (x + 1) - 1 //overflow - BOOM! with int x = MAX_INT int y = x; //no overflow Yes, this means that the program does different things depending on the level of optimization but are there any reordering/vectorizing possibilities that get blocked now?
  - pcwalton 12y ago
    > That surprises me—I would have thought a quick bit-test on the status register and conditional jump wouldn't be all that bad. 20%-30% performance loss at least, IIRC. > Are you thinking something like a software interrupt on integer overflow? Right.

pcwalton 12y ago

Rust does have those types, but they aren't free: overflow checking has a significant performance cost even when fully optimized. Because of the performance cost, a lot of code doesn't use the overflow-checking types. I think what we really need is for the hardware manufacturers to help us out here.

StefanKarpinski 12y ago
Agreed – hardware assistance would be a huge boon.
- mkup 12y ago
  BOUND instruction on x86 architecture exists for time immemorial, but not widely used and may be slow in modern microcode (like AAM/AAD and other stuff of handwritten assembly era, never emitted by compilers).
__david__ 12y ago
> …overflow checking has a significant performance cost even when fully optimized. That surprises me—I would have thought a quick bit-test on the status register and conditional jump wouldn't be all that bad. > I think what we really need is for the hardware manufacturers to help us out here. Are you thinking something like a software interrupt on integer overflow?
- dbaupp 12y ago
  There's the secondary effects of missed optimisations too: if every operation is checked for overflow, there's much less scope for reordering/collapsing/vectorising operations, (this is also especially important in tight loops where the core loop can easily be less than 20 instructions, so 2 extra is significant).
  - ufo 12y ago
    > if every operation is checked for overflow, there's much less scope for reordering/collapsing/vectorising operations Lets pretend that instead of "put a conditional jump after every operation", we try to model things as "pretend all integers are infinite precision, blow up if overflow happens at some point". So for example, we would be OK with rewriting int x = MAX_INT int y = (x + 1) - 1 //overflow - BOOM! with int x = MAX_INT int y = x; //no overflow Yes, this means that the program does different things depending on the level of optimization but are there any reordering/vectorizing possibilities that get blocked now?
- pcwalton 12y ago
  > That surprises me—I would have thought a quick bit-test on the status register and conditional jump wouldn't be all that bad. 20%-30% performance loss at least, IIRC. > Are you thinking something like a software interrupt on integer overflow? Right.