On Sunday, 6 May 2012 at 16:39:02 UTC, Mehrdad wrote:
Yes, but that misses the actual problem!
The problem isn't the _system_, it's the _compiler_.
If the language says overflow or underflow are undefined
behavior, then what the system does _doesn't matter one bit_,
because the compiler can optimize away the code entirely:
I know; as long as the number is within bounds it won't have any
issues. hopefully a simple suggestion would be to add a compiler
flag to check all results against overflow/underflow, of
add/subtract/multiply; and should it happen it throws an
exception; but asserts can likely do the same job if you have a
critical section you needed checked.
Under this case if you needed specific behavior you could use
the asm{} blocks, but as a whole I don't know. :(
I know I brought something similar to this before walter
regarding the carry bit and overflow and if you could have finer
control over it; but that ended up being rejected under the same
idea that if you really needed that control you can use the asm{}
block (I think, it's been a year or two I think).
It would be tedious to add checks after every instruction, so
the compiler would need to do it if you wanted those checks.
Either a flag would need to be set after a certain point in the
module that says 'act this way with math operations involving
over/underflow', or it is forced inside certain blocks as a new
try/catch, except... that might be
trysys {
a = b + c;
} catch (Carry c) {
//fix or whatever
//since we know it's a carry flag we don't need c
//so maybe catchsys(carry) instead??
}
Which might take an exception/like approach. But that seems
doubtful, since very likely the cases where it's needed is very
very very rare and refers back to asm or manual checks.
a = b + c;
if (a < b+c) {
//overflow?
//fails if MMX
}
or
if (a - b != c) {
//overflow?
}
Mmmm... Unfortunately I only have a few ideas and nothing
concrete.
