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
