[Vm-dev] Re: headerTypeBytes oddity

[Igor Stasenko]

sorry for ranting , but i tend to hate more and more VMMaker's code generator :)
It lacks a most critical feature, which is highly important for such
complex projects like VM: data encapsulation.
To write a quite simple method, i have spent 10 hours , rewriting it
again and again , splitting it to more shorter methods, just to keep
code readable (if 'readable' term can be applied to slang ;) .

I even started to write own C code generator, which would allow a
decomposition of a huge ObjectMemory+Interpreter to a set of smaller,
more isolated classes.
For instance, we can declare a special MemoryOop class to write:
 oop header   vs    self longAt: oop.
 oop isMarked  vs  ((self longAt: oop) bitAnd: MarkBit) ~= 0
 oop isIntegerObject vs  self isIntegerObject: oop
this list can be continued...


2009/2/18 Igor Stasenko <siguctua at gmail.com>:
> A headerTypeBytes ivar used in Interpreter, but initialized only once
> during its lifetime - in readImageFromFile: f HeapSize:
> desiredHeapSize StartingAt: imageOffset),
> and with same constants:
>
>        headerTypeBytes at: 0 put: BytesPerWord * 2.            "3-word header (type 0)"
>        headerTypeBytes at: 1 put: BytesPerWord.                "2-word header (type 1)"
>        headerTypeBytes at: 2 put: 0.                                   "free chunk (type 2)"
>        headerTypeBytes at: 3 put: 0.                                   "1-word header (type 3)"
>
> I think this initialization could be put into static var declaration,
> in #declareCVarsIn:
>        aCCodeGenerator
>                var: #headerTypeBytes
>                declareC: 'static sqInt headerTypeBytes[4] = { blablabla}'.
>
> then we don't have to pollute already complex #readImageFromFile:...
> method with odd stuff like this.
>
> It maybe not worth much attention for Squeak VM, but for Hydra, i
> found that this ivar placed into Interpreter struct (which means that
> each instance of interpreter will having separate  headerTypeBytes).
> There are tons of ivars in ObjectMemory and Interpreter and its hard
> to track all, which worth keeping on a per-interpreter basis :)
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>



-- 
Best regards,
Igor Stasenko AKA sig.