well the bitfield stuff would already work, thats fairly easy to implement. The only issue right now is that we rely on helvetia for the source code transformation. And I urge not to introduce custom syntax for slot creation, that doesn't make sense. Right now the class definition has always been hardcoded, which IMO is quite wrong. But by relying on first-class layouts in slots we can simply ask these objects what properties a class has. Just as a hint, first-class layouts render the format integer on classes basically useless. Since you can always query the layout and ask it for these properties. Thus the format should be used only at VM level to speed things up (the same for compact classes ;)). On 2011-03-24, at 22:04, Stéphane Ducasse wrote:
yes now we should probably avoid to have syntax in the class definition but in a description of the slots.
What means exactly: #identityHash => 20 => #Align => 32.
This is just an example
Yes I see that but I value real examples I cannot imagine :)
So we could have a nice BitFieldSlot class with nice message and creation interface (no magic intepretation needed and we would write something like
HeapField subclass: #ObjectHeaderLittleEndian instanceVar: 'identityHash <BitFieldSlot length: 20 aligned: 32> '
or something like that and it will be quite cool.
but it means a 20-bit unsigned integer field aligned on a 32-bit boundary. In the above #isPointers => 1 => #Boolean would mean a 1 bit-field accessed as a boolean (a flag). The above is close to the object header in the new GC I want to build.
For slots we did a first experience with marcus in 2008/9 where we show that we could get first class instanceVariable without speed penalties. We postpone our experience because it required a working new compiler and a complete rewrite of classBuilder. We want to be able to define active value hashTable relationship magritte like description and a lot more
So if you have ideas or wishes let us know.
Stef