Front page | perl.bootstrap |
Postings from July 2000
Benjamin Stuhl wrote: > From: Ken Fox <kfox@vulpes.com> > >The scheme48 project had a very good experience writing the core > >in a reduced dialect of scheme. This reduced dialect could be "easily" > >translated to a machine representation (they used C). I would support > >a similar implementation of perl6. (The reduced perl could be the > >ultra-portable microperl.) > > I like this idea. However, as performance is still somewhat of an issue (and > perl5, at least, eats immense amounts of memory even in C), I would propose > that the intermediate language (and that of the microperl6) be C, rather > than something higher level with more overhead. Joshua already outlined an implementation, but here's a bit more detail of how it could work. 1. A micro-perl compiler is written in micro-perl. It generates whatever language we want, probably C code. Micro-perl is an easily compiled subset of Perl 5: No eval, no dynamic symbol table stuff, no BEGIN/END, no overloading, no garbage collection, etc. Using Perl 5 solves the bootstrap problem quickly. (The subset defined as micro-perl can grow to become a subset of Perl 6 as we implement more functionality in the compiler, i.e. the compiler compiles itself.) 2. A support library is written for the generated C code. This can either be written in micro-perl or in C. Micro-perl buys portability, but C would be able to re-use parts of perl5, like the regexp engine. 3. A Perl virtual machine (PVM) is written in micro-perl. Large potions of the PVM will be shared with the micro-perl compiler -- we will want compiled code to be compatible with the PVM. The PVM must read a Perl 6 parse tree, i.e. the output of the Perl 6 parser. We need standardized file formats for storing a parse tree. 3. A Perl 6 parser is written in micro-perl by extending the micro-perl compiler. The parser generates a parse tree for the PVM. It could be part of the PVM if the PVM implements string eval directly. (The parser probably needs to embed the PVM to support BEGIN/END so we might as well just make it monolithic anyways.) Once the basics are working, we can go back and extend the compiler to compile Perl 6 instead of micro-perl by embedding a PVM into the generated code. (It would be nice to have a Perl 6-lite that can be compiled without needing the entire PVM built-in, maybe a pragma?) We should also go back and write a Java back-end for the micro-perl compiler and a Java support library. (If we can find Java to native code compilers of the same quality as C compilers, it would make sense to target Java as the first back-end instead of C.) This is a total change in direction from previous work done with Topaz. I'd like to hear from Chip on how difficult the Topaz design is to work with and whether the expense of a (high-quality) micro-perl compiler is worth it. BTW, it's the PVM and parser I'm mostly interested in -- moving those into micro-perl would make them much more fun to play with. - KenThread Previous | Thread Next