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:
 

--

best,

Eliot