Mitchell N Charity wrote:
On a minor note, re
CALL_VTABLE_0(meth, interp, pmc)
CALL_VTABLE_1(meth, interp, pmc, arg1)
CALL_VTABLE_2(meth, interp, pmc, arg1, arg2)
I suggest reordering arguments to
CALL_VTABLE_1(interp, meth, pmc, arg1)
or CALL_VTABLE_1(interp, pmc, meth, arg1)
Current parrot apis seem to all have the interpreter first,
As these are accessor macros to certain vtable methods, I'd rather have the method name first for clarity.
... with the
(unfortunate?) exception of some Parrot_jit_* functions, which place
jit_info before it.
This is an optimization for e.g. jit/i386, which has one interpreter already on the stack and thus only the PC has to be pushed for calling external functions.
A counter argument to all this might be if we expect to someday see a CALL_VTABLE_METH_1(interp, pmc, arg1) macro, or a similar function, and wish to minimize dissonance.
Yep, for heavily used function we might have specialized macros.
Mitchell
leo
