Am Freitag, 14. Dezember 2007 04:01 schrieb Will Coleda:
> From PDD17:
>
> Methods are declared in the body of the C<pmclass> or C<prole>
> declaration with C<METHOD>.
>
> METHOD inspect(STRING *what :optional, int got_what :opt_flag) {...}
>
> [NOTE: There is an older C<METHOD> keyword, which is deprecated. The
> current C<PCCMETHOD> will be renamed to C<METHOD>.]
I'm not really convinced that this is the best strategy. I might of cource
miss a lot, nethertheless will I try to summarize my concerns:
0) I'm aware of the fact that PCCMETHOD is more powerful
1) PCCMETHOD creates call code inline in the method body
Have a look at a simple accessor like in src/pmc/pmcproxy.c:
Parrot_PMCProxy_nci_methods(). There are +100 lines to just return a simple
PMC - i.e. an oneliner in the pmcproxy.pmc method[1]. These +100 lines are
emitted for each PCCMETHOD. I don't assume that this will have positive
effects on Parrot code size and instruction cache locality ;-) [2]
2) traditional METHOD calling code is outside of the function body.
Have a look at e.g. src/pmc/string.c: Parrot_String_nci_is_integer(). The
generated code is identical to the string.pmc's equivalent. The overhead of
calling the method from bytecode is outsourced elsewhere and common to all
PMC METHODs. This saves a lot of code size. But more importantly:
3) METHOD calls can be optimized in future parrot, PCCMETHOD can't
Due to the inlined calling code in PCCMETHOD, the original .pmc method body is
buried and hidden inside a lot of calling code. The original method isn't
reachable anymore. This isn't true for METHODs. The functional body is
unchanged and may somtimes be called more directly, if e.g. it's detected
(even at runtime) that this is just a plain accessor, or a simple call with
out named arguments or whatever. [3]
4) PCCMETHODs argument / return passing code is imposing more pressure on GC
There are 2 additional FixedIntegerArray->new() calls to create signature PMCs
for each method call. While these signature PMCs could be cached and consted,
it would be a PITA doing so. The single letter signature descriptors in
METHOD calls are more efficient - but less powerful, yes.
Summary:
I would use PCCMETHOD only for calls/returns, where features liked named
arguments are needed that aren't in METHOD and certainly not deprecate the
latter.
leo
[1] That would be of course:
return VTABLE_inspect_str(interp, SELF, CONST_STRING(interp, "methods"));
[2] remember that Parrot should be able to run on smaller devices too.
[3] see e.g. src/ops/pic.ops & src/pic.c: pic_callr__ for inlining simple
function calls on the fly, i.e. at runtime, when it's known to be safe to do
so.
