21–30 of 126 posts
> Overflow in the positive direction shall wrap around This appears to be defining signed integer overflow semantics, which prevents the compiler from doing certain basic optimizations, for example, that (x*2)/2 == x. Is that part of this? Has anyone measured the perf cost on a real program?
Fixed that for you.
> Overflow in the positive direction shall wrap around This appears to be defining signed integer overflow semantics, which prevents the compiler from doing certain basic optimizations, for example, that (x*2)/2 == x. Is that part of this? Has anyone measured the perf cost on a real program?
> for example, that (x&~1*2)/2 == x Fixed that for you.
If x is 3, then (x * 2) / 2 is also equal to 3 (as per the GP) but (x & ~1 * 2) / 2 is equal to 0.
(If you meant ((x & ~1) * 2) / 2, then that is equal to 2).
I'm curious why some old architectures didn't use two's complement for signed numbers. What advantage did one's complement or signed magnitude have over two's complement?
In addition to what's mentioned in the already great sibling comments, it's worth noting that IEEE floating point is signed-magnitude.
> Overflow in the positive direction shall wrap around This appears to be defining signed integer overflow semantics, which prevents the compiler from doing certain basic optimizations, for example, that (x*2)/2 == x. Is that part of this? Has anyone measured the perf cost on a real program?
It prevents risky optimisations; this now requires the compiler to prove that such optimisations won't change the semantics of the code, e.g. in your case by essentially proving that the high 2 bits of x (only 1 in the unsigned case, due to sign-extension) will never be set. ...and it could be argued that if the compiler couldn't prove that was true, then it just helped you find a possible overflow bug in the code. I…
Earlier quoted context omitted.
In addition to what's mentioned in the already great sibling comments, it's worth noting that IEEE floating point is signed-magnitude.
Sign-magnitude for the significand, and offset-binary for the exponent. The reason for this odd combination is probably historical.
Earlier quoted context omitted.
In addition to what's mentioned in the already great sibling comments, it's worth noting that IEEE floating point is signed-magnitude.
Sign-magnitude for the significand, and offset-binary for the exponent. The reason for this odd combination is probably historical.
Earlier quoted context omitted.
In addition to what's mentioned in the already great sibling comments, it's worth noting that IEEE floating point is signed-magnitude.
Is there a good way to represent floating points in order to do complement arithmetic?
> Overflow in the positive direction shall wrap around This appears to be defining signed integer overflow semantics, which prevents the compiler from doing certain basic optimizations, for example, that (x*2)/2 == x. Is that part of this? Has anyone measured the perf cost on a real program?
It prevents risky optimisations; this now requires the compiler to prove that such optimisations won't change the semantics of the code, e.g. in your case by essentially proving that the high 2 bits of x (only 1 in the unsigned case, due to sign-extension) will never be set. ...and it could be argued that if the compiler couldn't prove that was true, then it just helped you find a possible overflow bug in the code. I…
For example consider the classic binary search blunder: `mid = (low + high)/2`. Defining signed overflow may avoid the UB in computing mid, but now we have a surprise negative value and it's easy to guess what happens next.
It will be fun to see the trophies from this: perf regressions, bugs exposed, bugs fixed.