Compiler Backends (Programming Perl)

18.4. Compiler Backends

So, if Apache can compile a Perl program now and execute it later, why can't you? Apache and other programs that contain embedded Perl interpreters have it easy--they never store the parse tree to an external file. If you're content with that approach, and don't mind using the C API to get at it, you can do the same thing. See the section Section 18.4, "Embedding Perl (Using Perl from C)" in Chapter 21, "Internals and Externals", to learn how to access Perl from an enclosing C framework.

If you don't want to go that route, or have other needs, then there are a few options available. Instead of feeding the opcode output from the Perl compiler immediately into a Perl interpreter, you can invoke any of several alternative backends instead. These backends can serialize and store the compiled opcodes to an external file or even convert them into a couple different flavors of C code.

Please be aware that the code generators are all extremely experimental utilities that shouldn't be expected to work in a production environment. In fact, they shouldn't even be expected to work in a nonproduction environment except maybe once in a blue moon. Now that we've set your expectations low enough that any success at all will necessarily surpass them, it's safe to tell you how the backends work.

Some of the backend modules are code generators, like B::Bytecode, B::C, and B::CC. Others are really code-analysis and debugging tools, like B::Deparse, B::Lint, and B::Xref. Beyond those backends, the standard release includes several other low-level modules of potential interest to would-be authors of Perl code-development tools. Other backend modules can be found on CPAN, including (as of this writing) B::Fathom, B::Graph, B::JVM::Jasmin, and B::Size.

When you're using the Perl compiler for anything other than feeding the interpreter, the O module (that is, using the O.pm file) stands between the compiler and assorted backend modules. You don't call the backends directly; instead, you call the middle end, which in turn calls the designated backend. So, if you had a module called B::Backend, you would invoke it on a given script this way:

% perl -MO=Backend SCRIPTNAME

Some backends take options, specified as:

% perl -MO=Backend,OPTS SCRIPTNAME

Some backends already have their own frontends to invoke their middle ends for you so you don't have to remember their M.O. In particular, perlcc(1) invokes that code generator, which can be cumbersome to fire up.