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

Eliot Miranda eliot.miranda at gmail.com
Mon Dec 29 22:59:07 UTC 2014


Hi Bert,

On Dec 29, 2014, at 4:45 AM, Bert Freudenberg <bert at freudenbergs.de> wrote:

>>>> 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.
> 
> How about making SmallIntegers be 53 bits? Could the VM be as efficient if it masked off more bits? 
> 
> IMHO the additional 8 bits we get by going to 61 bits will not significantly enhance performance. In fact, the payoff is probably rather small beyond 32 bits (but still useful e.g. for bit shifts beyond the 32 bit boundary).
> 
> The question is why only some operations should fail if the SmallInt has more than 53 bits, or if we should consistently switch to LargeInts above that. OTOH wasting 8 bits in every SmallInt oop may not be a good tradeoff.

Doesn't feel right for me.  All we're considering is a few floating-point primitives which need an additional failure case.  Whereas truncating 64-bit SmallInteger has its own negative effects (microsecond clock range, many more large integers created, eg when dealing with addresses, temptation to find uses for missing bits, such as another ~2^11 tag patterns).  Good to mention an alternative but feels wrong to me.

> 
> - Bert -
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20141229/06db2814/attachment.htm


More information about the Vm-dev mailing list