Leopold Toetsch <[EMAIL PROTECTED]> wrote:
Yesterday on IRC chip and I went a bit through the following problem:
> --- integer.pmc 27 Mar 2005 13:14:18 -0000 1.25
> +++ integer.pmc 5 Apr 2005 16:02:26 -0000 1.26
> @@ -420,8 +420,23 @@
>
> void add (PMC* value, PMC* dest) {
> MMD_Integer: {
> - INTVAL a = PMC_int_val(SELF);
> - INTVAL b = PMC_int_val(value);
> + /*
> + * SELF and value can both be PMCs that inherit
> + * from Integer:
> + * cl = subclass "Integer", "MyInt"
[ ... ]
> +
> + INTVAL a = VTABLE_get_integer(INTERP, SELF);
> + INTVAL b = VTABLE_get_integer(INTERP, value);
Such a change would be needed for all MMD methods and vtable functions
that are also used by subclassed PMCs. This would add two function calls
to all infix operations. These calls are basically non-predictable
branches with long latency on modern CPUs accounting for about 10%
slowdown (tested with unoptimized parrot only).
Here's an idea for the infix MMD operators:
1) the PMC *can* provide two variants of an MMD type pair:
MMD_Integer: { ... } # Integer or subclassed Integer
MMD_EXACT_Integer: { ...} # Integer and only Integer
For simplicity the MMD_EXACT_* syntax denotes that the left operand is
of the exact type too - as the MMD_<type> label stands for the right
operand only (left is the class itself). This would be enough to catch
the most used arithmetic operations.
2) the MMD_init table is filled by Pmc2c.pm with type entries like:
($type << 1) | $exact
(dynamic PMCs would use 0 and 1 as the type isn't know at compile time)
3) in MMD lookup (static MMD_table) or in the distance function (dynamic
lookup) the types of the involved PMCs are known so that the appropriate
MMD function can be called.
4) all non-EXACT MMD functions have to use get_integer, get_number...
Well, yes that's of course an optimization. But the current
implementation of e.g Integer is using C<PMC_int_val> all over the place
and is incorrect in the presence of subclassing ...
Comments welcome,
leo
see t/pmc/mmd_23 and classes/integer.pmc
