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.
Dave