On 14.11.2014, at 17:56, Chris Muller <asqueaker at gmail.com> wrote:

>>> Anyway, something to be aware of -- anywhere we have true, false or
>>> nil used in a hash calculation, now has a different hash in Spur vs.
>>> Cog.  Maybe we should think about separating those objects' logical
>>> "value" hash from their identityHash in trunk..?  That could be useful
>>> when we move to 64-bit someday..
>> 
>> Remember that Spur has a common header format for both 32-bit and 64-bit
>> versions, so in both there is a 22-bit identityHash and hence the
>> identityHashes of all objects in a 64-bit Spur image bootstrapped from a
>> 32-bit Spur image will be _unchanged_.  Convenient. So no need to worry.
>> And it should be the case that a freshly bootstrapped 64-bit Spur image does
>> not need to be rehashed to function properly.
> 
> Suprising that their identityHash needs to change for Spur

It didn't *have* to change. Eliot could have just re-used the old identity hash of nil, true, and false. He probably just didn't think to do that.

> but not to go to 64-bit..

Spur already increases the number of bits to 22. It does not increase it again for 64 bits. 4 M different hashes should be enough, just like 4 M possible classes should be enough ;)

> Wait, I thought one of the benefits of 64-bit was to finally increase
> that small identityHash?

22 > 10

- Bert -



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4142 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20141114/66473362/smime.bin