PHP/Parrot
Stephen Thorne
I'm doing a bit of research and having a bit of fun reimplementing the PHP
parser, I've been using Python and dParser.sf.net (http://dparser.sf.net A
scannerless GLR parser).
I'm almost to the point where I can start taking an AST and doing code
generation, and I'd really like to be able to use Parrot as my target
machine.
I'm aware Parrot is a little bit of a moving target, and I'm wondering where I
can find the most up to date reference on it, for the purposes of writing a
code generator. I'm interested in a full set of instructions, and possibly an
existing compiler I can look at.
I see this page parrot website :
http://www.parrotcode.org/docs/parrot.pod.html
Is reading those documents my best bet? Some of them haven't been altered
since '01 (and in fact one of them seems a verbatim copy of an article on
perl.com). Does anyone have any other recommendatations? Should I just read
the source?
I'm not sure how I'm going to go about bootstrapping this (the bootstrapping
must be done for 100% php compatibility because its 'include' operator is
equivilient to reading a file and running eval($file_contents);). If Parrot
is eventually able to compile Python and that Python is capable of using C
extensions, then it should be possible to simply use the compiler I've
already written - Is that going to be even possible? Using C extensions from
Parrot-compiled bytecode? It seems thats in a bit of doubt (based on the
comments about the Python compiler using C code and having to use a drop-in
replacement code generator to solve the bootstrap issue).
Regards,
Stephen Thorne.
Luke Palmer
>
> I'm doing a bit of research and having a bit of fun reimplementing
> the PHP parser, I've been using Python and dParser.sf.net
> (http://dparser.sf.net A scannerless GLR parser).
>
> I'm almost to the point where I can start taking an AST and doing
> code generation, and I'd really like to be able to use Parrot as my
> target machine.
>
> I'm aware Parrot is a little bit of a moving target, and I'm
> wondering where I can find the most up to date reference on it, for
> the purposes of writing a code generator. I'm interested in a full
> set of instructions, and possibly an existing compiler I can look
> at.
For a complete list of instructions, grab the cvs and look at the
various .ops files. They are scattered with POD documentation about
each op they implement.
> I see this page parrot website :
> http://www.parrotcode.org/docs/parrot.pod.html
>
> Is reading those documents my best bet?
Definitely not. But it never hurts...
> Some of them haven't been altered since '01 (and in fact one of them
> seems a verbatim copy of an article on perl.com). Does anyone have
> any other recommendatations? Should I just read the source?
Basically yes, at this point. Again, the .ops files will probably be
the most useful for your purposes.
> I'm not sure how I'm going to go about bootstrapping this (the
> bootstrapping must be done for 100% php compatibility because its
> 'include' operator is equivilient to reading a file and running
> eval($file_contents);).
That's not a bootstrapping problem. You only need to bootstrap if php
actually parses itself with its own code. I don't think php is
powerful enough to do that ;-)
What you want to do is write your parser in Python, and use the Parrot
embedding interface (only in C at the moment) to run your code. You
can register a compiler with Parrot, and it will call out to your
Python routine that parses and generates code.
I see a problem, however. It's that you probably want to target IMCC
(Intermediate Code Compiler) when you're generating code, as opposed
to pure byte code (lest you reinvent several wheels). But, AFAIK,
IMCC has no such spiffy embedding interface. I'll let the IMCC
masters get back to you on that one.
> If Parrot is eventually able to compile Python and that Python is
> capable of using C extensions, then it should be possible to simply
> use the compiler I've already written - Is that going to be even
> possible?
Again, that's possible even if we don't support Python. Which we
don't. But we will :-)
> Using C extensions from Parrot-compiled bytecode? It seems thats in
> a bit of doubt (based on the comments about the Python compiler
> using C code and having to use a drop-in replacement code generator
> to solve the bootstrap issue).
Well, if you want to compile to parrot bytecode without an embedding
program, such that you can run php programs with the "parrot"
executable, then yes, I'm afraid you're stuck. In that case, you have
to implement a php parser in a language that can currently be compiled
to IMCC (or in php itself, in which case you could use php as a
bootstrap[1]). And with our current tools, that would be a pretty
hard thing to do.
So, I'll just suggest that you write your parser in whatever, and
embed parrot so you can register your compiler with parrot.
> Regards,
> Stephen Thorne.
Luke
[1] Just so we're clear, everyone, there is no bootstrap "problem" for
languages for which there already exist compilers. Those compilers
serve as fine bootstraps themselves. Perl 6 is different, because we
don't already have a Perl 6 compiler. That's the "problem".
Simon Glover
On 29 Jul 2003, Luke Palmer wrote:
> > G'day,
> >
>
> For a complete list of instructions, grab the cvs and look at the
> various .ops files. They are scattered with POD documentation about
> each op they implement.
The same documentation can also be found in the docs/ops/ subdirectory
-- it's generated from the .ops files at build time.
There's also a master list of the different ops:
/docs/pdds/pdd06_pasm.pod
Unfortunately, this is somewhat out of date (although I'm working on
getting it into shape).
> > I see this page parrot website :
> > http://www.parrotcode.org/docs/parrot.pod.html
> >
> > Is reading those documents my best bet?
>
> Definitely not. But it never hurts...
>
> > Some of them haven't been altered since '01 (and in fact one of them
> > seems a verbatim copy of an article on perl.com). Does anyone have
> > any other recommendatations? Should I just read the source?
>
> Basically yes, at this point. Again, the .ops files will probably be
> the most useful for your purposes.
I also strongly suggest reading the IMCC documentation in
languages/imcc/docs -- IMCC is an intermediate code compiler that
compiles something called Parrot Intermediate Language down to assembly
and/or bytecode. IMCC will handle a lot of the low-level code generation
details for you (eg. register spilling), so targeting this makes more
sense than targeting Parrot assembler or Parrot bytecode directly.
> > I'm not sure how I'm going to go about bootstrapping this (the
> > bootstrapping must be done for 100% php compatibility because its
> > 'include' operator is equivilient to reading a file and running
> > eval($file_contents);).
>
> That's not a bootstrapping problem. You only need to bootstrap if php
> actually parses itself with its own code. I don't think php is
> powerful enough to do that ;-)
>
> What you want to do is write your parser in Python, and use the Parrot
> embedding interface (only in C at the moment) to run your code. You
> can register a compiler with Parrot, and it will call out to your
> Python routine that parses and generates code.
>
> I see a problem, however. It's that you probably want to target IMCC
> (Intermediate Code Compiler) when you're generating code, as opposed
> to pure byte code (lest you reinvent several wheels). But, AFAIK,
> IMCC has no such spiffy embedding interface. I'll let the IMCC
> masters get back to you on that one.
>
> > If Parrot is eventually able to compile Python and that Python is
> > capable of using C extensions, then it should be possible to simply
> > use the compiler I've already written - Is that going to be even
> > possible?
>
> Again, that's possible even if we don't support Python. Which we
> don't. But we will :-)
Well, it won't be us that get pelted with pie if we fail :-)
But I digress...
> > Using C extensions from Parrot-compiled bytecode? It seems thats in
> > a bit of doubt (based on the comments about the Python compiler
> > using C code and having to use a drop-in replacement code generator
> > to solve the bootstrap issue).
>
Calling out from Parrot bytecode to external C library code should
and will be possible - this is the purpose of the native call interface
(NCI) routines that we already have.
Unfortunately, this is one of those areas that isn't terribly well
documented...
Good luck,
Simon