We are currently working on first-class slots and layouts in pharo.
This required some changes in how the class definitions are printed: ============================================= Object subclass: #Layout layout: ObjectLayout slots: { #host => Slot. #compactClassIndex => Slot. } classSlots: {} globals: '' category: #'Slot-Layout' ============================================= I adapted the MCClassDefinition >> definitionString to output our new class definitions. However squeaksource is not too happy with this and rewrites it completely using the default definition. Local mcz files contain the new definition, mcz files loaded form squeaksources still the old definition. Is there a way to still use squeaksources with our custom classes? thanks v(^_^)v camillo |
On Thu, Mar 24, 2011 at 11:43 AM, Camillo Bruni <[hidden email]> wrote: We are currently working on first-class slots and layouts in pharo. I like it! A great use for tuples. Not sure I like sots vs instanceVarables, but then I'm an old man ;) Have you thought about automatically creating accessors for byte data? I'm imagining
HeapField subclass: #ObjectHeaderLittleEndian type: #Bits fields: { #classTag => 20. #isPointers => 1 => #Boolean. #isIndexable => 1 => #Boolean.
#slotSize => 8 => #Align => 8. #identityHash => 20 => #Align => 32. #isMarked => 1 => #Boolean. #isForwarded => 1 => #Boolean.#isWeak => 1 => #Boolean. #isEphemeron => 1 => #Boolean. } classSlots: {} globals: '' category: #'VMMaker-MemoryManager'
|
>
> > I like it! A great use for tuples. Not sure I like sots vs instanceVarables, but then I'm an old man ;) > Have you thought about automatically creating accessors for byte data? I'm imagining > > HeapField subclass: #ObjectHeaderLittleEndian > type: #Bits > fields: { > #classTag => 20. > #isPointers => 1 => #Boolean. > #isIndexable => 1 => #Boolean. > #slotSize => 8 => #Align => 8. > #identityHash => 20 => #Align => 32. > #isMarked => 1 => #Boolean. > #isForwarded => 1 => #Boolean. > #isWeak => 1 => #Boolean. > #isEphemeron => 1 => #Boolean. } > classSlots: {} > globals: '' > category: #'VMMaker-MemoryManager' 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. 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 |
On Thu, Mar 24, 2011 at 1:45 PM, Stéphane Ducasse <[hidden email]> wrote:
This is just an example 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.
|
On 24 March 2011 21:52, Eliot Miranda <[hidden email]> wrote:
> > > On Thu, Mar 24, 2011 at 1:45 PM, Stéphane Ducasse > <[hidden email]> wrote: >> >> > >> > >> > I like it! A great use for tuples. Not sure I like sots vs >> > instanceVarables, but then I'm an old man ;) >> > Have you thought about automatically creating accessors for byte data? >> > I'm imagining >> > >> > HeapField subclass: #ObjectHeaderLittleEndian >> > type: #Bits >> > fields: { >> > #classTag => 20. >> > #isPointers => 1 => #Boolean. >> > #isIndexable => 1 => #Boolean. >> > #slotSize => 8 => #Align => 8. >> > #identityHash => 20 => #Align => 32. >> > #isMarked => 1 => #Boolean. >> > #isForwarded => 1 => #Boolean. >> > #isWeak => 1 => #Boolean. >> > #isEphemeron => 1 => #Boolean. } >> > classSlots: {} >> > globals: '' >> > category: #'VMMaker-MemoryManager' >> >> 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 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. kekeke... i like it when people see a direct benefits for themselves :) >> >> 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 >> >> > > -- Best regards, Igor Stasenko AKA sig. |
In reply to this post by Eliot Miranda-2
>
> > 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 > > > |
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 |
Free forum by Nabble | Edit this page |