Embedding Parrot in Perl
Luke Palmer
Perl. I ran into a few problems:
1) I don't know XS :-) (good way to learn, though)
2) What do I put as stacktop in Parrot_init()? I can't just use a
local variable in the calling function, because it will return and
there might be something lower than that later...
3) I'd like to have the PIR compiler available to this embedded
interpreter. What would be the best way to do that?
Thanks,
Luke
Benjamin Goldberg
Luke Palmer wrote:
>
> I started working on some XS code for embedding a Parrot interpreter in
> Perl. I ran into a few problems:
>
> 1) I don't know XS :-) (good way to learn, though)
>
> 2) What do I put as stacktop in Parrot_init()? I can't just use a
> local variable in the calling function, because it will return and
> there might be something lower than that later...
If our DoD is no longer walking the C stack, then stacktop should no
longer be needed. Until the code is changed, just pass NULL.
> 3) I'd like to have the PIR compiler available to this embedded
> interpreter. What would be the best way to do that?
>
> Thanks,
> Luke
--
$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;}
Nicholas Clark
> I started working on some XS code for embedding a Parrot interpreter in
> Perl. I ran into a few problems:
>
> 1) I don't know XS :-) (good way to learn, though)
Have you looked at what Arthur's been up to with ponie?
You can get a snapshot from:
http://opensource.fotango.com/ponie/po...@34.tar.gz
Yes, it's huge. It currently includes all of parrot and all of perl, which
means two separate Unicode implementations.
Nicholas Clark
Juergen Boemmels
> Luke Palmer wrote:
> >
> > I started working on some XS code for embedding a Parrot interpreter in
> > Perl. I ran into a few problems:
> >
> > 1) I don't know XS :-) (good way to learn, though)
> >
> > 2) What do I put as stacktop in Parrot_init()? I can't just use a
> > local variable in the calling function, because it will return and
> > there might be something lower than that later...
>
> If our DoD is no longer walking the C stack, then stacktop should no
> longer be needed. Until the code is changed, just pass NULL.
AFAIK, the stack is still walked. (I don't like this but thats a
diffrent story). So Parrot_init() should be called with a real
stacktop. A typical codefragment to do this is:
struct Parrot_Interp *interpreter;
interpreter = Parrot_new();
Parrot_init(interpreter, &interpreter);
> > 3) I'd like to have the PIR compiler available to this embedded
> > interpreter. What would be the best way to do that?
IMCC implements the (static) functions imcc_compile_pir and
imcc_compile_pasm in parser_util.c. You can take a look at them. But
be careful imcc uses some global data in the parser and the lexer, so
this is not reentrant.
bye
boe
--
Juergen Boemmels boem...@physik.uni-kl.de
Fachbereich Physik Tel: ++49-(0)631-205-2817
Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906
PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Leopold Toetsch
> Benjamin Goldberg <ben.go...@hotpop.com> writes:
>> If our DoD is no longer walking the C stack, then stacktop should no
>> longer be needed. Until the code is changed, just pass NULL.
> AFAIK, the stack is still walked. (I don't like this but thats a
> diffrent story). So Parrot_init() should be called with a real
> stacktop. A typical codefragment to do this is:
The stack is walked, but only from bottom up to the stack at run-loop
level (at least it should be, lo_var_ptr isn't set properly yet).
The extra argument for Parrot_init can go away. There is nothing
unanchored on the stack, when the interpreter starts running.
> bye
> boe
leo
Leopold Toetsch
>
> 2) What do I put as stacktop in Parrot_init()?
Its gone. stacktop is now set internally before entering the run loop.
> Thanks,
> Luke
leo