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

[Nicolas Cellier]

2014-12-26 23:07 GMT+01:00 John McIntosh <johnmci at smalltalkconsulting.com>:

>
> I question would be how long would it take to crowd source a Sunit that
> covers the entire range of 2^64?  When we worked on the 32bit clean image I
> ended up doing the 2^32 range for small integers and large integers after
> discovering at issue at 2^24
>
>
It depends, if testing the 2^32 combinations took you 1hour, you might get
around the 2^64 in less than 500,000 years...
Unless of course you can parallelize on the 1,5 billion active PC in the
world (can a good virus do that?)

If you deal with 2^32 tests in 1 second, then less than 150 years will be
enough with a single machine (I advise you to wait a few more years before
launching the test, that might be the best strategy...)



>
> Sent from my iPhone
>
> On Dec 26, 2014, at 1:58 PM, Nicolas Cellier <
> nicolas.cellier.aka.nice at gmail.com> wrote:
>
>
>
> 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/2646909c/attachment.htm