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

[Eliot Miranda]

On Fri, Dec 26, 2014 at 2:45 PM, Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com> wrote:

>
>
>
> 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...)
>
>
Remember we only have to test 2^61 values ;-).  Clearly the exhaustive test
is not going to work, John.  Time to think of edge cases ;-)



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


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