[Vm-dev] Potential problems with 64bit spur large SmallInteger comparison

Eliot Miranda eliot.miranda at gmail.com
Fri Dec 26 18:44:02 UTC 2014


Hi Nicolas,

On Fri, Dec 26, 2014 at 7:48 AM, Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com> wrote:

>
> One of the problem I foresee is this one:
>
>     1.0e17 >= 100000000000000001
>
> indeed, the (generated) primitive currently convert the SmallInteger to
> double, and this one is true:
>
>     1.0e17 >= 100000000000000001 asFloat
>
> In 32 bit Spur/COG with 30 bit max magnitude, it was OK because every
> conversion SmallInteger -> Double was exact - like all integer in the range
> [-2^53,2^53] - see Float class>>maxExactInteger
>
> In 64 bits Spur, this might not be the case anymore since some
> SmallInteger exceed this range...
>

Thanks for the head's up.  You're quite right:

(1 << 60 - 1) asFloat asInteger = (1 << 60 - 1) false

So the (generated) primitive must be protected with some range test.
>

So in cases where we do double CMP integer or integer CMP double the
primitive must fail if the SmallInteger has more than 52 bits of
significance?  That's reasonable.  I need to review the StackInterpreter
code to make sure it does the same.  I'm pretty sure it doesn't do so right
now.

-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20141226/4a47e793/attachment.htm


More information about the Vm-dev mailing list