In 1996, someone announced a challenge - the first person to write a compiler suite for Perl would win a laptop. Malcolm Beattie stepped up to the challenge, and won the laptop with his B suite of modules. Many of these modules have now been brought into the Perl core as standard modules.
The Perl compiler is not just for compiling Perl code to a standalone executable - in fact, some would argue that it's not at all for compiling Perl into a standalone executable. We've already seen the use of the B::Terse and B::Tree modules to help us visualise the Perl op tree, and this should give us a hint as to what the Perl compiler is actually all about.
The compiler comes in three parts: a frontend module, O, which does little other than turn on Perl's -c (compile only, do not run) flag, and loads up a backend module, such as B::Terse which performs a specific compiler task, and the B module which acts as a low-level driver.
The B, at the heart of the compiler, is a stunningly simple XS module which makes Perl's internal object-like structures - SVs, ops, and so on - into real Perl-space objects. This provides us with a degree of introspection: we can, for instance, write a backend module which traverses the op tree of a compiled program and dump out its state to a file. (This is exactly what the B::Bytecode module does.)
It's important to know what the Perl compiler is not. It's not something which will magically make your code go faster, or take up less space, or be more reliable. The backends which generate standalone code generally do exactly the opposite. All the compiler is, essentially, is a way of getting access to the op tree and doing something potentially interesting with it. Let's now take a look at some of the interesting things that can be done with it.