Alek Storm <[EMAIL PROTECTED]> wrote:
The invoke vtable method is supposed to take one argument - the
address of the opcode immediately following the invokecc opcode, so we
can return to it later. It then returns the address of the subroutine
to jump into. The problem is that, in C, the invoke method takes and
returns an opcode_t*, and PIR can't handle that, so I've attached a
patch correcting the problem by converting the argument and return
value so the PIR plays nice.
Any ParrotObject overriding the invoke vtable method is probably not
going to care about addresses. Luckily, all we have to do is return
the address we're given, so everything goes back to normal after the
method's finished. The downside is that you're going to have to come
with a more creative workaround in order to be passed any arguments
that the method is called with.
I don't think that's the right route to take. Exposing the pc to PIR-land
code seems dangerous and I don't think there's much point. As a PIR user, I
want the invoke vtable to behave just like any other PIR subroutine.
This gets us close to what I want:
void* invoke(void *next) {
STRING *meth = CONST_STRING(interp, "__invoke");
STRING *meth_v = CONST_STRING(interp, "invoke");
PMC *sub = Parrot_find_vtable_meth(interp, pmc, meth_v);
if (PMC_IS_NULL(sub))
sub = find_or_die(interp, pmc, meth);
(void*) Parrot_run_meth_fromc_args(interp, sub,
pmc, meth, "??", next);
return next;
}
I've tested it and it works with the original code that Richard gave. The
only thing left to do is handle return values; I'm still working on that. If
I can get return values working properly, I'll check in a fix.
--
Matt Diephouse
http://matt.diephouse.com
