At 12:19 AM -0400 6/7/04, John Malmberg wrote: >Craig A. Berry wrote: >> >> http://www.perldoc.com/perl5.8.4/pod/perlcompile.html >> >>I think what this gets you in that subset of cases for which it even >>works is a Perl op-tree implemented in C. In other words, you get a >>C program that executes the particular stream of Perl byte codes that >>make up your program. > >To compile Perl directly, you need to interface to a back end code generator.
True, but we need to define "code" here. For Perl, it generally means bytecode that is run on the Perl bytecode engine, which is roughly equivalent to what Java folks call a virtual machine. I say "roughly" because Perl is a dynamically typed language (unlike Java or C#). In Perl, "8.341" may just be a string right up until the point you do arithmetic on it, at which point it becomes a number. >For OpenVMS, the back end translators used by HP are GEM and VCG, and as far as I >know there is no public documentation for either. Nor is either capable of generating Perl bytecodes :-). >The Gnat ADA project uses the code generator in GCC for this, and if the other Perl >compilers use this, then there may be a way to get this done on OpenVMS. Good point. If someone were to target the GCC code generator, and if this code generator were sufficiently smart enough to generate the right instructions on Alpha and Itanium (no small task), then there's no particular reason this wouldn't work as well on VMS as elsewhere. What I think you'd want to do would be to make a cross assembler, as it were, one that converts the pseudo-instructions known as Perl bytecodes into native machine instructions. And if you were going to invest the effort required to do that, you'd really want to use the Perl 6 bytecodes (a clean sheet of paper reimplementation known as Parrot) rather than Perl 5. For more on Parrot, which will form the guts of Perl 6, and most likely some future version of Perl 5, see <http://www.parrotcode.org/>. But none of this is what was under discussion in the desire to compile Spamassassin. The "executable" one would distribute would not be an OpenVMS VAX, Alpha, or I64 image; instead it would be a platform-independent stream of bytecodes read off disk and run on the Perl virtual machine. This would save you the parsing, syntax checking, bytecode optimization, and probably a few other steps I'm forgetting at the moment. It would not eliminate the virtual machine. It would not have any particular speed advantages over a server process that compiles to bytecode once at start-up and processes requests continuously until shut down. It could have some deployment advantages if bundled with a Perl interpreter -- see Nicco's post in this thread. -- ________________________________________ Craig A. Berry mailto:[EMAIL PROTECTED] "... getting out of a sonnet is much more difficult than getting in." Brad Leithauser
