8 ms·
I'd like to see integer types for C/C++ that are able to saturate or trap on overflow - or both types. I'm pretty sure it's even been proposed as a C standard b
by wyldfire 4y ago
I'd like to see integer types for C/C++ that are able to saturate or trap on overflow - or both types. I'm pretty sure it's even been proposed as a C standard but was rejected or postponed.
It seems like a really obvious feature that's easy to support but isn't.
- klysm 4y agoTotally agree. Overflowing silently is almost never what you want. Sometimes it’s useful but that’s the rare case.
- ljosifov 4y ago+1. Would be great to have integer NAN, INF and -INF supported in h/w.
- icsa 4y agoThe k language has implemented this capability (in software) for decades. https://code.kx.com/q/ref/#datatypes https://code.kx.com/q/ref/#datatypes
- ljosifov 4y agoYes, true - thanks. Love that in K in particular, and I like K and array languages in general. Another thing they get right. :-)
- Symmetry 4y agoLikewise. That's what I was expecting going in rather than Lovecraftian monstrosities like INT_NAN. Plus they're actually something that's supported in some existing ISAs.
- deleted 4y ago[deleted]
- beardyw 4y ago> trap on overflow What do you see happening in that case?
- wyldfire 4y agoThe program terminates - depending on context, I suppose. I don't know what all toolchains/backends do but some will generate an unaligned load or some other architecturally illegal code (__builtin_trap). or you could trap to some handler.
- colejohnson66 4y agox86 has had the `INTO` (interrupt on overflow) instruction (just a one byte form of `INT 4`) for decades. After an `ADD` or other arithmetic operation, you would `INTO` to trap it. However, because compilers love exploiting undefined behavior for speedups, they don't emit that instruction, so it's actually fairly slow on modern processors.
- wyldfire 4y agoRight, well a new type would give them that flexibility because I can opt in to the trap or saturate.
- josefx 4y agoI am not sure if I remember it correctly, but wasn't the problem that you had to explicitly call INTO after every operation? You didn't have a global flag to set or a flag bit in the add instruction, you had to explicitly emit the check. So using it carried a significant performance penalty over leaving the operation unchecked. > However, because compilers love exploiting undefined behavior for speedups Except if the behavior had been well defined any attempt to catch overflow would violate the standard - see unsigned integers for reference. > so it's actually fairly slow on modern processors. Are you sure that having a potential branch every second operation, that depends directly on the result of the preceding operation, has at any point in time not been horribly slow?
- phkahler 4y agoSaturating arithmetic is available on some DSPs and may be available to C programs via #pragma on those architectures. IMHO this is a burden to every ALU and instruction that does not need the feature. We should not push application specific features like that down to the basic hardware. We'd also need to provide language support for it.
- brandmeyer 4y agoSaturating arithmetic is probably not all that expensive, since its been in every ARM SIMD unit (and sometimes also scalar) for many years. You just pay a little bit in latency when using those instructions.
- zajio1am 4y agoStandard (signed) integers in C could be implemented to trap on overflow. Overflow on signed integer is undefined operation, like NULL dereferencing or division by zero, so trap is perfectly expected behavior. The issue is that unsigned integers must not trap on overflow, and CPUs, if they could be configured to trap on arithmetic overflow, usually do not have separate opcodes for overflowing arithmetic operations and trapping arithmetic operations.
- renox 4y ago> The issue is that unsigned integers must not trap on overflow You forgot to add 'in C', in Zig they have the same behaviour as signed integers.
- adrian_b 4y agoMost compilers, like gcc or clang, have a compile option to trap on integer overflow, instead of leaving the behavior to be undefined for such cases. For example with gcc one should always use these compile options, unless there exists an extremely serious reason to do otherwise: -fsanitize=address,undefined -fsanitize-undefined-trap-on-error These options provide correct behavior not only on overflows, but also on out-of-bounds accesses and other C undefined operations.
- Unklejoe 4y agoIt’s fine for debug builds, but people should be aware that building with the address sanitizer enabled balloons the size of the executable and slows it down tremendously.
- adrian_b 4y agoOne should always measure to see if there is a noticeable slowdown or not. That is what I have meant by "an extremely serious reason to do otherwise". For many programs the speed is determined by things like the throughput or latency of accessing the main memory, or by I/O operations, or by interaction with an user, in which case the sanitize options have negligible influence on speed. When necessary, they should be turned off only for specific well tested functions whose performance is limited by CPU computation in registers or in cache memory, and they should remain on for the rest of the program.
- mikewarot 4y agoFree Pascal (fpc) supports trapping on overflow, it uses the overflow flag and tests it after integer operations, it's pretty basic. Here's the assembly output of in Int64 add # [16] c := a + b; movq U_$P$TEST_$$_A(%rip),%rdx movq U_$P$TEST_$$_B(%rip),%rax addq %rdx,%rax jno .Lj9 call FPC_OVERFLOW .Lj9: movq %rax,U_$P$TEST_$$_C(%rip) It should be easy to support in C/C++, as FPC uses the same LLVM backend.
- csmpltn 4y agoThat's hardware specific, right? You're not guaranteed to have a solution on every platform.
- mikequinlan 4y agoAll platforms can detect overflow in one way or another; for example by checking for an unexpected sign change.
- chrisseaton 4y agoAMD64 addressing modes cannot detect overflow, and this is where in practice 90% of arithmetic is done!
- mikequinlan 4y agoI don't know specific AMD64 addressing modes, but you should always be able to detect overflow in signed 2s complement addition by checking to see if both addends are positive and the result is negative. There is a similar check for subtraction.
- chrisseaton 4y agoYeah, but the point is addressing modes fuse addition and multiplication and using the result, so there's no opportunity to check anything after the operations.