This *all* includes vtable functions like add_int() or add_float() too,
I presume. For these we have left argument dispatch only. But what is
the right argument? A PerlInt, TclInt, PyInt (or ..Float)? Or is it
assumed to be the same as the left argument type?

leo

I've now implemented MMD for PerlInt's bitwise_xor as a test case. Syntax
looks like this:

    void bitwise_xor (PMC* value, PMC* dest) {
MMD_PerlInt: {
        VTABLE_set_integer_native(INTERP, dest,
            PMC_int_val(SELF) ^ PMC_int_val(value));
             }
MMD_DEFAULT: {
        VTABLE_set_integer_native(INTERP, dest,
            PMC_int_val(SELF) ^
            VTABLE_get_integer(INTERP, value));
             }
    }

This creates two functions:

    Parrot_PerlInt_bitwise_xor()
    Parrot_PerlInt_bitwise_xor_PerlInt()

with the body parts from above and these initializer code snippet:

        { MMD_BXOR, enum_class_PerlInt, 0,
                    (funcptr_t) Parrot_PerlInt_bitwise_xor },
        { MMD_BXOR, enum_class_PerlInt, enum_class_PerlInt,
                    (funcptr_t) Parrot_PerlInt_bitwise_xor_PerlInt }

leo

[ another MMD performance compare ]

Just an update. Last benchmark still called MMD via the vtable. Here is
now a compare of calling MMD from the run loop:

$ parrot -C mmd-bench.imc
vtbl add  PerlInt PerlInt 1.072931
vtbl add  PerlInt Integer 1.085116
MMD  bxor PerlInt PerlInt 0.849723
MMD  bxor PerlInt Integer 0.989387

$ parrot -j mmd-bench.imc
vtbl add  PerlInt PerlInt 0.685505
vtbl add  PerlInt Integer 0.692237
MMD  bxor PerlInt PerlInt 0.628078
MMD  bxor PerlInt Integer 0.790955

JITed vtable add calls directly into the vtable, while the MMD <bxor> is
still a function that calls mmd_dispatch.

Compiled with -O3, 5 Meg operations on Athlon 800.

leo

leo

At 12:54 PM +0200 5/7/04, Leopold Toetsch wrote:

The three options are promotion to PMC, leaving these in the vtable,
or having a mmd-variant for them.

I'm up for the mmd-variant version. We just have a one-dimensional
table for PMC/int, PMC/float, and PMC/string functions and have the
ops directly dispatch to it. Seems simpler than stuffing the
functions into the base MMD table too.
--
                                         Dan

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

We currently have left type only dispatch as a default for a
non-existent right type, this is in type slot 0.

What about this:
- assign fix class enums (we need that anyway for PBC consistency)
- assign class enums 1..3 to utility PMCs like Env that don't do MMD
- use these 3 type slots in the one and only MMD table for int, float,
  string

leo

At 12:43 PM +0200 5/8/04, Leopold Toetsch wrote:

I'm mildly hesitant to have three special columns in the table (and
I'm not 100% sure someone won't do something really bizarre with Env)
but this seems OK. The one downside to it is that it potentially
anchors the rows a bit more than we might otherwise want--it's
possible to save a lot of space if each row in the MMD table has a
starting number and length prepended, so that the row for type 87
would be 5 words long if it only had entries for types 66, 67, and
68. (That paper I posted a link to a while back describes some of
this stuff)

OTOH that's all implementation detail, so lets go ahead and do it.
--
                                         Dan

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

[rubbish:]

We have to extend the function range of the table. Using
type slots for functions is just nonsense.

leo