"Leopold Toetsch" <[EMAIL PROTECTED]> wrote:
Strange, but it exists for just on case (well not strange, there are just
more negative numbers ...):
$ cat div.pasm
set I0, 0x80000000
Which is the largest negative number we can represent in 32 bit integers
(-2147483648).
div I1, I0, -1
print I1
print "\n"
end
Which I'd kinda expect to give back -(-2147483648) = 2147483648, apart from
that's one beyond the biggest positive number and thus overflows to what we
had before, 0x80000000, the largest negative number. Eww.
Running it on PPC gives:
$ ./parrot div.pasm
0
Ugh.
And on x86:
$ ./parrot div.pasm
Floating point exception
Looks kinda...broken. Oh, wait, it's x86... :-)
What shall we do?
Go to the pub. It won't fix the problem, but we'll feel better about it.
Abstract it like division by zero and throw an exception?
I guess the Right Exception to throw would be an integer overflow exception
if we did that.
Just ignore it?
It's kinda worth asking "what is an I register" here. They're native size
already, so we could just say "they have native overflow/wrap-around
behaviour" too and then we can ignore it. It really depends how far we want
to hide away the underlying hardware. There are always PMCs available to
put in specific behaviour and checking of cases like this, and it may well
be that certain languages we support want to give one promise with regard to
questions like this while others want to give another. On the other hand,
if we catch and throw an exception on overflow already with I registers then
it may make sense to be consistent and handle this too.
Jonathan
