Thanks,
Luke
> How does one call a parrot Sub from C and get the return value(s)?
I'd vote for stuffing args into the interpreter, calling the sub's
invoke() method, then digging through the registers to pull out the
return values (see e.g. Parrot_pop_argv in method_util.c, which may be
outdated). Then again, it would be _your_ pain, not mine ;).
/s
The Parrot-C interface could simply come with
some wrapper functions that would do this for
you. I suppose this could be done with a couple
printf/scanf-like functions, except they would
work with pcc parameters instead of strings.
(This would probably tie in to the subroutine
sinatures discussed in 'calling conventions,
variable-length parameter lists'.)
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
Good question. Its very similar to classes/Eval.pmc:invoke().
You would do:
- call runops_int(interp, offset)
- returning from the sub is by invoke'ing the return continuation with
address 0, which you have put in P1
- param passing is like PCC (pdd03)
> Thanks,
> Luke
leo
Togos wrote:
>
> --- Sean O'Rourke <soro...@cs.ucsd.edu> wrote:
> > Luke Palmer <fibo...@babylonia.flatirons.org>
> > writes:
> >
> > > How does one call a parrot Sub from
> > > C and get the
> >
> > I'd vote for stuffing args into the
> > interpreter, calling the sub's invoke()
> > method, then digging through the registers
> > to pull out the return values (see e.g.
> > Parrot_pop_argv in method_util.c, which
> > may be outdated). Then again, it would be
> > _your_ pain, not mine ;).
>
> The Parrot-C interface could simply come with
> some wrapper functions that would do this for
> you. I suppose this could be done with a couple
> printf/scanf-like functions, except they would
> work with pcc parameters instead of strings.
Would that be a printf-like to put args onto the stack, with the format
string being the subroutine's prototype, and a scanf-like to get return
values from the stack, with the format string being the return context?
If we didn't have NCI, using these two functions in the other order (to
get the arguments passed in, then to return values) might be useful for
functions which want to be called from Parrot.
Hmm... even with the existance of NCI, doing that might be useful --
having a function process it's arguments itself, rather than having NCI
do it, might be more efficient.
Oh, and maybe this idea could probably replace "pxs.c"?
> (This would probably tie in to the subroutine
> signatures discussed in 'calling conventions,
> variable-length parameter lists'.)
--
$a=24;split//,240513;s/\B/ => /for@@=qw(ac ab bc ba cb ca
);{push(@b,$a),($a-=6)^=1 for 2..$a/6x--$|;print "$@[$a%6
]\n";((6<=($a-=6))?$a+=$_[$a%6]-$a%6:($a=pop @b))&&redo;}
Okay, now I've got a pretty nice XS interface for embedding and
introspecting into a parrot interp from Perl. I just figured out what
you meant by "offset", but the way I compute it is, well:
void
_run_sub (interp, pmc)
Parrot_Interp interp
PMC* pmc
INIT:
PMC* retc = pmc_new_noinit(interp, enum_class_RetContinuation);
CODE:
VTABLE_init(interp, retc);
VTABLE_set_integer_native(interp, retc, 0);
interp->pmc_reg.registers[0] = pmc;
interp->pmc_reg.registers[1] = retc;
runops_int(interp, ((void*)VTABLE_invoke(interp, pmc, NULL) - (void*)interp->code->byte_code)>>2);
Is there a better way to do it (other than stylistic concerns)? Oh,
don't worry about parameter passing, I've that handled in the Perl front
end.
Also, I can't seem to figure out how to make a CSub which calls to a
user-provided perl sub. It seems I need more metadata, specifically,
the SV containing the sub. Should I just subclass CSub and include it
in pmc_val or somesuch? Or does CSub already do what I need?
Thanks again,
Luke
> Also, I can't seem to figure out how to make a CSub which calls to a
> user-provided perl sub.
Please use the NCI interface. You can call arbitrary C functions with
it. S. classes/parrotio.pmc or Parrot_compreg() and the docs.
> Thanks again,
> Luke
leo