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

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Fri Dec 26 21:58:43 UTC 2014


2014-12-26 22:46 GMT+01:00 Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com>:

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

So defining a specialized  loadFloatOrInt53From: for float/integer compare
primitive/bytecode may do the job...


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


More information about the Vm-dev mailing list