Object header access (was: [Vm-dev] MemoryAccess added as separate
package in VMMaker SqueakSource project)
David T. Lewis
lewis at mail.msen.com
Sun Dec 14 19:24:54 UTC 2008
On Sat, Dec 13, 2008 at 10:09:33PM -0500, David T. Lewis wrote:
> On Sat, Dec 13, 2008 at 03:07:28PM -0800, Eliot Miranda wrote:
> > One of the things I hate most about Slang is the exposed bit twiddlng for
> > object headers. i.e. there is nothing that maps to the level of a C struct
> > with bit fields. In my Cog Stack interpreter I made a class
> > InterpreterStackPage map to a struct. this class is only a container. I'd
> > like to do the same for the object header so in Smalltalk one would have a
> > proper object type that one could send messages like classFormatField and
> > markBit to and have that map down onto a struct bitfield dereference which
> > would improve readability in both Smalltalk and C. Any thoughts on that?
> Excellent idea. I'm afraid that MemoryAccess does nothing to address it, but
> I see no reason that it can't be done, and it would probably be helpful in
> migrating object headers from one format to another.
On second thought I'm not so sure this is a such good idea, at least
not with the current approach for slang code generation. When code is
generated from a class outside of the ObjectMemory hierarchy, the mechanism
is hidden and not easily browsed. If there was a new class ObjectHeader,
it would need to be outside of the ObjectMemory or InterpreterPlugin
hierarchies, so the translation would be awkward.
I guess that what's missing is a better notion of class A and class B being
able to generate code for a method in class A without class B being in the
same hierarchy. To some extent, that is done now with the translation
dictionary in CCodeGenerator. That approach could be extended to do code
generation for e.g. a new class ObjectHeader but I'm not sure it would be
an improvement over the current bit twiddling.
Maybe an idiom such as "anObject objectHeader classFormatField" would make
sense if the code generator could be convinced to find the TParseNode parse
tree from class B and include it in the parse tree for a method in class A.
For MemoryAccess, I just slipped the MemoryAccess class in as a superclass
of ObjectMemory and InterpreterPlugin (or remove it from the hierarchy to
"disable" it). It's something of a hack to be sure, but it seems reasonable
to think of ObjectMemory as being implemented "on top of" a memory access
layer (either MemoryAccess or sqMemoryAccess.h as the case may be) in the
same sense that the Interpreter is implemented "on top of" ObjectMemory.
More information about the Vm-dev