The newest NQP variants have complete support for all Parrot opcodes natively, so anything you can do in PIR you can do with NQP as well (plus some nicer syntax). You do lose a certain amount of performance currently because of various Parrot issues that NQP successfully works around, but those performance problems are the subject of some current and planned work and shouldn't be treated as a permanent condition.
You may also want to take a look at an NQP library like Kakapo[1], which adds a large amount of functionality and niceness to NQP. Again, performance is a bit of an issue but performance can always be improved. --Andrew Whitworth [1] http://www.gitorious.com/kakapo On Tue, May 11, 2010 at 11:55 PM, Jon Gentle <[email protected]> wrote: > Hello again, > > A few months ago, I introduced myself and my idea of having parrot be able > to host static languages. Since then, I've been working on updating my > compiler to be more modern and flexible, and at the same time parse > fortran. Apparently, when I started working on fortran, I was unaware of > how subtly the complexity of fortran is, especially the "whitespace is > completely insignificant" part. I've made some progress and I'm feeling > pretty good about eventually getting fortran to completely parse even if > I've only got about one third of the test suite parsed successfully so far. > > So, in attempt to keep some momentum going, I've decided to switch gears > slightly and work on an educational programming language, PL/0. Since I > have the parser portion of my compiler sane and usable thanks to fortran, > I'd like to start getting it to output something useful. Unfortunately, my > code generation stage previously was a hackish mess that I'm quite glad to > get rid of. It was what I would describe as a macro system, including line > leading sigals, action letters, and a list of parameters with some fancy > substitutions. No code blocks, no proper subroutines and nothing was easy > to write. The only part I was proud of at all was the substitution code. > I'd just rather leave that code generation behind me. > > Which leads me to my current problem, which is what to replace it with. > I've been debating it with myself, and briefly pinged the IRC channel for > suggestions. I'm at a loss of how to go forward and would like some insight > into what the best method really would be. > > Some of the basics of the problem are: > > * I will have the syntax tree already built, so that data needs to be passed > along > * Because of the way my compiler works, I'll have chunks of text that > represent the logic > * Each chunk will then need to become callable > * I chose not to write in C so I'm okay having to create a reasonable amount > of glue code > > Since I'm abandoning my current code generation, that leads me to think that > I have two basic options. The first is to merely output text, retain some > substitution code, and allow a separate program process it and handle the > real code generation. The other option would be to embed something to > handle the code generation. I'm leaning a little more towards the embedding > since it seems like it would be the more sense. > > But both solutions lead to the same question: what should I use to generate > code? PIR seems to be a candidate since it looks like I can pass parrot a > string of PIR code directly and get a callable PMC out of it, but it seems > to me like PIR wasn't designed to be the engine behind code generation, but > rather hand written or the output of code generation. So then NQP comes to > mind, but I wonder how easy it is to pass a chunk of HLL text to be compiled > and executed would be. That would also open up the possibility of using any > HLL to act as the logic behind the code generation. The downside seems that > it would be more work on the glue code side. The upside to that would be > that I might be able to leverage it to generate non-parrot output. > > So in short, I'd like some advice on how to effectively embed parrot into a > project with the intention of using it to generate bytecode. If anyone is > interested, the compiler code is on github at http://github.com/atrodo/draak > . > > -Jon Gentle > > _______________________________________________ > http://lists.parrot.org/mailman/listinfo/parrot-dev > > _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
