> G'day, > > 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".
