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, with the
(unfortunate?) exception of some Parrot_jit_* functions, which place
jit_info before it. That gets us to (interp, meth, pmc, arg1).
The choice between (meth, pmc, arg1) and (pmc, meth, arg1) is related
to whether we will find it more natural to think in terms of
a. multimethods (meth.(obj args)), or
b. traditional hierarchical (obj.meth.(args)) or message
passing (obj.(meth args)).
It seems to be simply a human factors choice. The variable order
doesn't affect the macros, and seemingly has little effect on any
code manipulation tools.
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.
But whatever. We can always fiddle later. I wouldn't have mentioned
it if not for the opportunity to flag that the jit functions are using
a perhaps somewhat different argument convention.
Mitchell
