This compiler backend takes Perl source and generates C source code
corresponding to the flow of your program. In other words, this
backend is somewhat a ``real'' compiler in the sense that many people
think about compilers. Note however that, currently, it is a very
poor compiler in that although it generates (mostly, or at least
sometimes) correct code, it performs relatively few optimisations.
This will change as the compiler develops. The result is that
running an executable compiled with this backend may start up more
quickly than running the original Perl program (a feature shared
by the C compiler backend--see B::C) and may also execute
slightly faster. This is by no means a good optimising compiler--yet.
If there are any non-option arguments, they are taken to be
names of objects to be saved (probably doesn't work properly yet).
Without extra arguments, it saves the main program.
Force apparently unused subs from package Packname to be compiled.
This allows programs to use eval ``foo()'' even when sub foo is never
seen to be used at compile time. The down side is that any subs which
really are never used also have code generated. This option is
necessary, for example, if you have a signal handler foo which you
initialise with $SIG{BAR} = "foo". A better fix, though, is just
to change it to $SIG{BAR} = \&foo. You can have multiple -u
options. The compiler tries to figure out which packages may possibly
have subs in which need compiling but the current version doesn't do
it very well. In particular, it is confused by nested packages (i.e.
of the form A::B) where package A does not contain any subs.
Instead of generating source for a runnable executable, generate
source for an XSUB module. The boot_Modulename function (which DynaLoader can look for) does the appropriate initialisation and runs
the main part of the Perl source that is being compiled.
Delays FREETMPS from the end of each statement to the end of the group
of basic blocks forming a loop. At most one of the freetmps-each-*
options can be used.
Note that cc_harness lives in the B subdirectory of your perl
library directory. The utility called perlcc may also be used to
help make use of this compiler.
These aren't really bugs but they are constructs which are heavily
tied to perl's compile-and-go implementation and with which this
compiler backend cannot cope.
Standard perl calculates the target of ``next'', ``last'', and ``redo''
at run-time. The compiler calculates the targets at compile-time.
For example, the program
sub skip_on_odd { next NUMBER if $_[0] % 2 }
NUMBER: for ($i = 0; $i < 5; $i++) {
skip_on_odd($i);
print $i;
}
produces the output
024
with standard perl but gives a compile-time error with the compiler.
The context (scalar or array) of the ``..'' operator determines whether
it behaves as a range or a flip/flop. Standard perl delays until
runtime the decision of which context it is in but the compiler needs
to know the context at compile-time. For example,
@a = (4,6,1,0,0,1);
sub range { (shift @a)..(shift @a) }
print range();
while (@a) { print scalar(range()) }
generates the output
456123E0
with standard Perl but gives a compile-time error with compiled Perl.
Compiled Perl programs use native C arithmetic much more frequently
than standard perl. Operations on large numbers or on boundary
cases may produce different behaviour.
