Vasily Chekalkin wrote:
Hello.
I'm going to merge tt452_reduce_mmd_branch back to trunk.
Ok. I'm not going to merge this branch any more. It's wrong in many ways.
1. Using "switch" statement blindly will cause a lot of regressions on
language implementers (see TT#713).
2. Providing manual MULTI methods and fallback to MMD in "default" case
of switch statement will always be incomplete and require manual
maintaining.
3. Having 3 versions (VTABLE, MULTI and METHOD) of dispatch is way too
many to support.
4. (Just rant) 240+ VTABLE methods doesn't fit into my head.
5. We can override some VTABLE's but not all of them. For example
Array.get_string_keyed isn't overridable at all.
Instead I propose to use chromatic's idea about "optimisation to
collapse unnecessary MULTI" with some (small) variations:
1. Restrict manual implementation of VTABLE for overridable methods.
(All methods which accept only PMC* considered overridable. E.g. "add"
is overridable, but add_int isn't).
2. Improve Pmc2c to create switch based VTABLE for MULTI.
3. (In ideal world) Remove METHOD support and use MMD for it.
For example Integer.add will be implemented as:
MULTI PMC* i_add(Integer) { ... }
MULTI PMC* i_add(BigInt) { ... }
MULTI PMC* i_add(Float) { ... }
MULTI PMC* i_add(DEFAULT value) {
STATICSELF.i_add_float(value.get_number()
}
Pmc2c will generate something like this:
PMC* VTABLE_i_add(PMC *value) {
INTVAL type = VTABLE_type(INTERP, value);
switch(type) {
case enum_class_Integer:
return Parrot_Integer_multi_i_add_Integer(SELF, value);
case enum_class_BigInt:
return Parrot_Integer_multi_i_add_BigInt(SELF, value);
case enum_class_Float:
return Parrot_Integer_multi_i_add_Float(SELF, value);
default:
if (type < enum_class_core_max)
return Parrot_Integer_multi_i_add_DEFAULT(SELF, value);
else
Parrot_mmd_multi_dispatch(.., "i_add", "PP->", ...);
}
}
Pros:
1. Less code to maintain in each PMC.
2. Consistent behaviour across all PMCs (including non-core).
3. VTABLE dispatch for Core PMCs will be fast.
Cons:
1. Pmc2c will be harder to maintain.
--
Bacek
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
