can you hum a few bars on how the Smalltalk code looks using this and not using this?

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?

On Sat, Dec 13, 2008 at 2:24 PM, David T. Lewis <lewis@mail.msen.com> wrote:
I made a separate package for MemoryAccess (Slang implementation of
sqMemoryAccess.h) and uploaded it to the VMMaker project on SqueakSource.
In the VMMaker project, VMMaker-dtl.110.mcz contains all prerequisites
for MemoryAccess-dtl.1.mcz.

Some support code patches are required to use this for Unix VM generation
(patches attached). See also http://wiki.squeak.org/squeak/6081 for an
overview that may be useful if merging into another VMMaker code base.

MemoryAccess makes no changes to generated VM code until it is enabled
("MemoryAccess enable"), so it can be safely loaded into an image and
used as needed.

I find that using MemoryAccess helps the C compiler find type casting
errors, and produces code that is easier to follow in a debugger. On my
computer, there is no performance difference between the MemoryAccess
slang versus CPP macros in sqMemoryAccess.h.