2014-12-26 23:07 GMT+01:00 John McIntosh <johnmci@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@gmail.com> wrote:

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

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

 

Hi Nicolas,

On Fri, Dec 26, 2014 at 7:48 AM, Nicolas Cellier <nicolas.cellier.aka.nice@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