develooper Front page | perl.perl6.internals | Postings from October 2002

[RFC] Buffer/PMC unification, variable/value vtable split, tied scalars

Thread Next
Leopold Toetsch
October 25, 2002 02:55
[RFC] Buffer/PMC unification, variable/value vtable split, tied scalars
Message ID:
Attached is a test program showing some features, how a PMC could look 
like in the future.

PMCs/Buffer are both based on the same bufferlike structure - I called 
it Pobj (Parrot Object)
- There is no need, that all PMCs are of same size, the bufferlike code 
in smallobjects.c / headers.c takes care of these.
- mark/GC would be unified - marking all Pobj's does it.
- Eliminates a fair amount on now duplicate code.

Steps towards that would include:
- encapsulate flags and other Buffer/PMC members in accessor macros
- unify the BUFFER/PMC_xx_FLAGs
- unify mark and general code clean up

Variable/value VTABLE split
As layed out by Dan, the access to a value inside a PMC has - in the 
general form - to be done in 2 separate steps:
- get the variable PMC (+ handle side effects like tied variables)
- get the value out of this PMC
The same rule holds for setting a value inside a PMC.

By splitting the VTABLE into different pieces, we can avoid to do these 
separate steps for plain scalars, which wouldn't need it.

Please have a look at »scalar_vt« and »tied_scalar_vt« in the test 
program, how this could work:
For plain scalars the first vtable->var.get_integer does it all - finito 
  - like current operation. For tied scalars, the vtable has different 
entries, to accomplish both steps.

The test program shows additionally, how other methods would be 
implemented - they all are in the vtable->val part, calling 
vtable->var.get/set_{type} for obtaining/setting values.

Putting these methods into the vtable->val piece provides for a small 
vtable->var piece, which only holds (duplicates of) the direct 
get/set_{type} methods. So vtable duplication is minimal.

3) Tied scalars
Based on above scheme, the test program shows, how this actually works 
by tieing a scalar to a (fixed) function, which increments the value on 
each access. Using this tied scalar in an »add« methods does the right 

Unsolved - as mentioned in the program - is how to handle these now 
dynamically allocated vtable (pieces) WRT memory management. But we 
could probably allocate these vtable pieces as bufferlike small objects 
and keep them in pools. Many different PMCs (all of the same type/class) 
are having the same vtable anyway. Subclassing or tieing a variable 
would generate one or more new vtable pieces for this variable type.

Finally, the test program can be run in the parrot main dir by:

$ cc -o tt -Wall -g tt.c -Iinclude && ./tt

(The syntax for different platforms might differ ;-)

Please give it a try, to see implications for different platforms and - 
as always - coments welcome,

especially e.g.
- how would references fit, how will the look like
- objects and methods/attributes and subclassing
- and the whole and everything ...

Have fun,

Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About