<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 14, 2014 at 9:20 AM, Bert Freudenberg <span dir="ltr"><<a href="mailto:bert@freudenbergs.de" target="_blank">bert@freudenbergs.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
On 14.11.2014, at 17:56, Chris Muller <<a href="mailto:asqueaker@gmail.com">asqueaker@gmail.com</a>> wrote:<br>
<br>
>>> Anyway, something to be aware of -- anywhere we have true, false or<br>
>>> nil used in a hash calculation, now has a different hash in Spur vs.<br>
>>> Cog. Maybe we should think about separating those objects' logical<br>
>>> "value" hash from their identityHash in trunk..? That could be useful<br>
>>> when we move to 64-bit someday..<br>
>><br>
>> Remember that Spur has a common header format for both 32-bit and 64-bit<br>
>> versions, so in both there is a 22-bit identityHash and hence the<br>
>> identityHashes of all objects in a 64-bit Spur image bootstrapped from a<br>
>> 32-bit Spur image will be _unchanged_. Convenient. So no need to worry.<br>
>> And it should be the case that a freshly bootstrapped 64-bit Spur image does<br>
>> not need to be rehashed to function properly.<br>
><br>
> Suprising that their identityHash needs to change for Spur<br>
<br>
</span>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.<br></blockquote><div><br></div><div>Right. I thought since identityHashes would be changing (class identityHashes must change for Spur's class table, and there are more than 2^10 objects in an image) I would assign new hashes to all objects in the image that needed them and start with 1, 2 & 3 as the hashes for the first objects, nil, false & true. Any system which relies on identityHashes not changing from V3 to Spur will be broken anyway, so why keep the hashes for those objects?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> but not to go to 64-bit..<br>
<br>
</span>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 ;)<br>
<span class=""><br>
> Wait, I thought one of the benefits of 64-bit was to finally increase<br>
> that small identityHash?<br>
<br>
</span>22 > 10<br></blockquote><div><br></div><div>Right (see both Bert's & Levente's responses). Spur lifts the number of identityHashes from 2^10 to 2^22. There's no room for more in a 64-bit system. SPur is designed to go beyond 32-bits, but it isn't designed for terabyte heaps. One step at a time ;-)</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888">- Bert -</font></span><br></blockquote></div><div><br></div>-- <br><div class="gmail_signature">best,<div>Eliot</div></div>
</div></div>