[Vm-dev] ImageSegment, objects header and addresses

[David T. Lewis]

On Thu, Jul 29, 2010 at 10:27:03AM +0200, Mariano Martinez Peck wrote:
>  
> On Tue, Jul 27, 2010 at 6:10 PM, K. K. Subramaniam <kksubbu.ml at gmail.com>wrote:
> 
> > On Tuesday 27 Jul 2010 8:02:29 pm Mariano Martinez Peck wrote:
> > > Now....the line I don't understand is this:
> > >
> > >     self longAt: oop put: newOop + HeaderTypeFree.
> > >
> > > Because 'self longAt: oop'
> > > will answer the object header of oop. And there, it stores a number (the
> > > offset). Is this possible?
> > >
> > > In addition, it not only stores the offset, by it plus the flag
> > > HeaderTypeFree.
> > >
> > > I really don't understand how you can plus an offset and the flag. What
> > is
> > > the result? how should I interpret that?
> >
> 
> Hi Subbu.
> 
> 
> > A oop is an offset. Since every oop is aligned to a 4-word boundary
> 
> ok.....each oop is 4-word -> 32 bits, 4 bytes. I am right?  One is used to
> mark SmalltalkIntegers. But here, that doesn't matter.
> 
> > the least
> > significant two bits are always zero.
> 
> why? I don't understand this. Why the last two bits are always zero? because
> ImageSegment assumes that the size of the segment will be much smaller?
> 

See first the class comment of ObjectMemory for the overall description
of how this works. In that comment (and throughout much of the code for
ObjectMemory and Interpreter) the term "pointer" is the same as "oop".
An object memory pointer is a byte-addressable offset into the object
memory, and the object memory is just a big array of 32-bit words (or
64-bit words in the case of the 64-bit object memory format).

The use of a byte-addressable object memory pointer (rather than a
32-bit or 64-bit word addressable pointer as one might have expected)
has the nice property that only every fourth (or eighth) value actually
points to a valid address in the object memory. That means that any time
you see a pointer that does not point to a valid word, you know that
it is not really a pointer after all.

This is what permits the trick of saying that if the oop has an odd
value (low order bit is set), then treat it as a short integer and
use the remaining 31 bits of the "oop" as the value of that integer.
Computationally, it's just a matter of check the low order bit, and
if it is set, shift right one to obtain the integer value.

This is also the reason that for any valid object memory pointer
(aka oop), the two low-order bits of the pointer must be zero.
Anything else points to something other than a 4 (or 8) byte boundary
in the object memory, and therefore is not pointing to a valid location
in the object memory.

Dave

> 
> Sorry if this is a very newbie question.
> 
> yes, I noticed this
> 
>     "type field values"
>     HeaderTypeSizeAndClass := 0.
>     HeaderTypeClass := 1.
>     HeaderTypeFree := 2.
>     HeaderTypeShort := 3.
> 
> in initializeObjectHeaderConstants
> 
> 
> > So these two bits are re-used for a
> > typecode (0..3).
> >
> >
> Thanks for the help
> 
> Mariano
> 
> 
> 
> > HTH .. Subbu
> >