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

[Nicolas Cellier]

2014-12-26 19:44 GMT+01:00 Eliot Miranda <eliot.miranda at gmail.com>:

>
> 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?
>

Well, up to 53 bits it's OK to convert an integer to a double, it's
lossless.



> 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.
>

#primitiveLessThan does only compare integers, but #bytecodePrimLessThan
tries to be smarter and invoke #primitiveFloatLess:thanArg: then
#loadFloatOrIntFrom:


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