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