[CVS ci] use-vtable-macros-4: ops files and the rest

[Leopold Toetsch]

This patch completes the changes WRT VTABLE_ macros.

Short note: *.ops are not changed, the substitution happens during
rewriting in lib/Parrot/Op.pm. So using vtable methods in ops files
should match the s/// rule in Op.pm:rewrite_body().

Now we could start implementing the real vtable changes, iff they are
already layed out :-)

leo

[Dan Sugalski]

At 10:36 AM +0200 5/20/03, Leopold Toetsch wrote:
>This patch completes the changes WRT VTABLE_ macros.
>
>Short note: *.ops are not changed, the substitution happens during
>rewriting in lib/Parrot/Op.pm. So using vtable methods in ops files
>should match the s/// rule in Op.pm:rewrite_body().

Cool. We can, I presume, go ahead and use the macros anyway, though,
right? If so, I'd love to start transitioning over.

>Now we could start implementing the real vtable changes, iff they
>are already layed out :-)

Cool. Shall we, then, start grouping these things and seeing what we
might want to share, what might want to be optional, and whatnot?
--
Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk

[Leopold Toetsch]

Dan Sugalski wrote:

> At 10:36 AM +0200 5/20/03, Leopold Toetsch wrote:
>
>> This patch completes the changes WRT VTABLE_ macros.
>>
>> Short note: *.ops are not changed, the substitution happens during
>> rewriting in lib/Parrot/Op.pm. So using vtable methods in ops files
>> should match the s/// rule in Op.pm:rewrite_body().
>
>
> Cool. We can, I presume, go ahead and use the macros anyway, though,
> right? If so, I'd love to start transitioning over.

Yep.

>> Now we could start implementing the real vtable changes, iff they are
>> already layed out :-)
>
>
> Cool. Shall we, then, start grouping these things and seeing what we
> might want to share, what might want to be optional, and whatnot?

I think we should first clean vtable.tbl.
s. [RfC] disable unused vtable entries

pmc2c.pl could just skip unused vtable entries (instead of dying in line
373 - or surround the body with #if 0/#endif).

And WRT grouping: AFAIK does the var/value split imply, that we have to
duplicate all get_<type>_* and set_<type>_* methods. A typical method
like C<add_int> does look like this:

iself = VTABLE_get_integer(INTERP, SELF);
idest = iself + value;
VTABLE_SET_integer(INTERP, dest, idest);

The add_int (or all other methods doing some arith/bool/... action) are
unchanged.
The VTABLE_get acts on the variable-related part of the vtable and pulls
in the value that the var has. This is for our plain scalars just the
same as getting the value directly.

so our vtable would be:

struct _vtable {
...
get_integer_method_t get_integer;
set_integer_method_t set_integer;
...
struct {
...
get_integer_method_t get_integer;
set_integer_method_t set_integer;
...
} var;
}

The VTABLE_get_integer above is vtable->var.get_integer (which happens
to be the same method as vtable->get_integer).

Now for tied variables, references or whatever[1], the var-part of the
vtable[2] has different methods - obtaining the variable to act on.

As the whole vtable is still a statically[3] allocated thing, we would
need vtable "templates" for all combinations of possible variable access.

Some questions and notes:

[1] what kind of variables are we going to handle with this scheme actually?

[2] Currently e.g. in perlint.pmc we have a lot of:
if(value->vtable == &Parrot_base_vtables[enum_class_PerlNum]) {
...
this should be replaced by:
if (VTABLE_type(INTERP, value) == enum_class_PerlNum)
as the address of the vtable could differ. The type() aka ->base_type
stays the same.

[3] I'm not sure, if we can go with static vtables. I can imagine, that
we end up with allocated vtables per class/variable-type combination.
But this depends on [1].

leo