<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On 19.08.2009, at 06:38, Michael van der Gulik wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><br>If you look at the implementation of ProtoObject>>identityHash, it is primitive 75. If you look at the implementation of Object>>asOop, it is also primitive 75. So, coincidentally, yes, it is an OOP (object pointer).<br></blockquote><div><br></div><div>Wrong. You can neither access nor "dereference" OOPs from inside the image. </div><div><br></div><div>The comment in Object>>asOop does not reflect reality anymore.</div><div><br></div><div>The original (Blue Book) Smalltalk-80 VM used an object table. OOPs were indices into the object table. They were even, because each object table entry stored a 16 bit pointer to the actual object. Odd OOPs represented SmallIntegers in theri upper 15 bits. So the lowest bit indicated whether an OOP was an object table index or an "immediate" integer value. OOPs never changed over the lifetime of an object, garbage collection (which moves objects around in memory) only had to change the object table entry.</div><div><br></div><div>In the Squeak VM, there is no object table. It uses a "direct pointer" model. Each OOP is 32 bits (*). Odd OOPs still represent SmallIntegers in their upper 31 bits, but even OOPs are a direct pointer to an object. This means that when garbage is collected and an object moves, its OOP changes. This is not observable from the image.</div><div><br></div><div>Now, in Smalltalk-80, #identityHash was calculated as the OOP divided by 2 (they where even, remember? SmallIntegers are their own identityHash), because the OOP was constant for each object, so a good base for knowing identity. In Squeak, an equivalent was needed. There are 12 bits in the Squeak object header that get assigned when the object is created, and are moved around with the object when compacting memory. Primitive 75 returns these hash bits now, despite its name:</div><div><br></div><div>primitiveAsOop</div><div><div><span class="Apple-tab-span" style="white-space:pre"> </span>| thisReceiver |</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>thisReceiver := self stackTop.</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>self success: (self isIntegerObject: thisReceiver) not.</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>successFlag</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>ifTrue: [self pop:1 thenPushInteger: (self hashBitsOf: thisReceiver)]</div></div><div><br></div><div><div>hashBitsOf: oop</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>^ ((self baseHeader: oop) >> 17) bitAnd: 16rFFF</div></div><br><blockquote type="cite">The intention however was just to print out a number that is unique for each different instance so that you can see whether two variables are pointing to the same morph. This is useful for debugging.<br></blockquote><br></div><div>Indeed. IMHO, all uses of #asOOP should be replaced by #identityHash (outside of the VMMaker package anyway), and the comment in asOOP updated (or remove it altogether).</div><div><br></div><div> <span class="Apple-style-span" style="font-size: 12px; "><div style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><div style="font-family: Helvetica; "><span class="Apple-style-span" style="font-family: Helvetica; ">- Bert -</span></div><br class="Apple-interchange-newline"></div></span> </div>(*) Even in a VM compiled on a 64 bit host OOPs are 32 bits. Only in "64 bit images" OOPs are extended to 64 bits, but they are not in use yet. And we might rather like to re-introduce an object table anyway, which even with 32 bit OOPs would give us 2 billion objects ;)</body></html>