7.3. What B and O Provide

To see how we can built compilers and introspective modules with B, we need to see what B and the compiler front-end O give us. We'll start with O, since it's simpler.

7.3.1. O

The guts of the O module are very small - only 48 lines of code - because all it intends to do is set up the environment ready for a back-end module. The back-ends are expected to provide a subroutine called compile which processes the options that are passed to it and then returns a subroutine reference which does the actual compilation. O then calls this subroutine reference in a CHECK block.

CHECK blocks were specifically designed for the compiler - they're called after Perl has finished constructing the op tree and before it starts running the code. O calls the B subroutine minus_c which, as its name implies, is equivalent to the command-line -c flag to perl: compile but do not execute the code. It then ensures that any BEGIN blocks are accessible to the back-end modules, and then calls compile from the back-end processor with any options from the command line.

7.3.2. B

As we have mentioned, the B module allows Perl-level access to ops and internal variables. There are two key ways to get this access: from the op tree, or from a user-specified Perl "thing".

To get at the op tree, B provides the main_root and main_start functions. These return B::OP-derived objects representing the root of the op tree and the start of the tree in execution order respectively:

%  perl -MB -le 'print B::main_root; print B::main_start'

For everything else, you can use the svref_2object function which turns some kind of reference into the appropriate B::SV-derived object:

%  perl -MB -l
	  $a = 5; print B::svref_2object(\$a); 
	  @a=(1,2,3); print B::svref_2object(\@a);
(Yes, it's normal that the objects will have the same addresses.)

In this tutorial we'll concentrate on the op-derived classes, because they're the most useful feature of B for compiler construction; the SV classes are a lot simpler and quite analogous.