X-Git-Url: https://perl5.git.perl.org/perl5.git/blobdiff_plain/4375e838ae24b385ae79fa7b6918e613bedaaee6..4ed3fda49b8590b1f2536acfe87ecdec36a6d516:/pod/perlcompile.pod diff --git a/pod/perlcompile.pod b/pod/perlcompile.pod index e5544ec..505ce68 100644 --- a/pod/perlcompile.pod +++ b/pod/perlcompile.pod @@ -9,17 +9,16 @@ internal form (a parse tree) which is then optimized before being run. Since version 5.005, Perl has shipped with a module capable of inspecting the optimized parse tree (C), and this has been used to write many useful utilities, including a module that lets -you turn your Perl into C source code that can be compiled into an +you turn your Perl into C source code that can be compiled into a native executable. The C module provides access to the parse tree, and other modules ("back ends") do things with the tree. Some write it out as -bytecode, C source code, or a semi-human-readable text. Another -traverses the parse tree to build a cross-reference of which -subroutines, formats, and variables are used where. Another checks -your code for dubious constructs. Yet another back end dumps the -parse tree back out as Perl source, acting as a source code beautifier -or deobfuscator. +semi-human-readable text. Another traverses the parse tree to build a +cross-reference of which subroutines, formats, and variables are used +where. Another checks your code for dubious constructs. Yet another back +end dumps the parse tree back out as Perl source, acting as a source code +beautifier or deobfuscator. Because its original purpose was to be a way to produce C code corresponding to a Perl program, and in turn a native executable, the @@ -37,8 +36,7 @@ what problems there are, and how to work around them. The compiler back ends are in the C hierarchy, and the front-end (the module that you, the user of the compiler, will sometimes -interact with) is the O module. Some back ends (e.g., C) have -programs (e.g., I) to hide the modules' complexity. +interact with) is the O module. Here are the important back ends to know about, with their status expressed as a number from 0 (outline for later implementation) to @@ -46,30 +44,6 @@ expressed as a number from 0 (outline for later implementation) to =over 4 -=item B::Bytecode - -Stores the parse tree in a machine-independent format, suitable -for later reloading through the ByteLoader module. Status: 5 (some -things work, some things don't, some things are untested). - -=item B::C - -Creates a C source file containing code to rebuild the parse tree -and resume the interpreter. Status: 6 (many things work adequately, -including programs using Tk). - -=item B::CC - -Creates a C source file corresponding to the run time code path in -the parse tree. This is the closest to a Perl-to-C translator there -is, but the code it generates is almost incomprehensible because it -translates the parse tree into a giant switch structure that -manipulates Perl structures. Eventual goal is to reduce (given -sufficient type information in the Perl program) some of the -Perl data structure manipulations into manipulations of C-level -ints, floats, etc. Status: 5 (some things work, including -uncomplicated Tk examples). - =item B::Lint Complains if it finds dubious constructs in your source code. Status: @@ -160,7 +134,7 @@ I to the file I: =head2 The Decompiling Back End The Deparse back end turns your Perl source back into Perl source. It -can reformat along the way, making it useful as a de-obfuscator. The +can reformat along the way, making it useful as a deobfuscator. The most basic way to use it is: $ perl -MO=Deparse myperlprogram @@ -183,9 +157,6 @@ one-liners: rename $was, $_ unless $was eq $_; } -(this is the I program that comes in the I directory -of the Perl source distribution). - The decompiler has several options for the code it generates. For instance, you can set the size of each indent from 4 (as above) to 2 with: @@ -219,57 +190,7 @@ To disable context checks and undefined subroutines: See L for information on the options. -=head2 The Simple C Back End - -This module saves the internal compiled state of your Perl program -to a C source file, which can be turned into a native executable -for that particular platform using a C compiler. The resulting -program links against the Perl interpreter library, so it -will not save you disk space (unless you build Perl with a shared -library) or program size. It may, however, save you startup time. - -The C tool generates such executables by default. - - perlcc myperlprogram.pl - -=head2 The Bytecode Back End - -This back end is only useful if you also have a way to load and -execute the bytecode that it produces. The ByteLoader module provides -this functionality. - -To turn a Perl program into executable byte code, you can use C -with the C<-b> switch: - - perlcc -b myperlprogram.pl - -The byte code is machine independent, so once you have a compiled -module or program, it is as portable as Perl source (assuming that -the user of the module or program has a modern-enough Perl interpreter -to decode the byte code). - -See B for information on options to control the -optimization and nature of the code generated by the Bytecode module. - -=head2 The Optimized C Back End - -The optimized C back end will turn your Perl program's run time -code-path into an equivalent (but optimized) C program that manipulates -the Perl data structures directly. The program will still link against -the Perl interpreter library, to allow for eval(), C, -C, etc. - -The C tool generates such executables when using the -opt -switch. To compile a Perl program (ending in C<.pl> -or C<.p>): - - perlcc -opt myperlprogram.pl - -To produce a shared library from a Perl module (ending in C<.pm>): - - perlcc -opt Myperlmodule.pm - -For more information, see L and L. +=head1 Module List for the Compiler Suite =over 4 @@ -290,53 +211,13 @@ called something like this: This is like saying C in your Perl program. -=item B::Asmdata - -This module is used by the B::Assembler module, which is in turn used -by the B::Bytecode module, which stores a parse-tree as -bytecode for later loading. It's not a back end itself, but rather a -component of a back end. - -=item B::Assembler - -This module turns a parse-tree into data suitable for storing -and later decoding back into a parse-tree. It's not a back end -itself, but rather a component of a back end. It's used by the -I program that produces bytecode. - -=item B::Bblock - -This module is used by the B::CC back end. It walks "basic blocks". -A basic block is a series of operations which is known to execute from -start to finish, with no possibility of branching or halting. - -=item B::Bytecode - -This module is a back end that generates bytecode from a -program's parse tree. This bytecode is written to a file, from where -it can later be reconstructed back into a parse tree. The goal is to -do the expensive program compilation once, save the interpreter's -state into a file, and then restore the state from the file when the -program is to be executed. See L -for details about usage. +=item B::Concise -=item B::C - -This module writes out C code corresponding to the parse tree and -other interpreter internal structures. You compile the corresponding -C file, and get an executable file that will restore the internal -structures and the Perl interpreter will begin running the -program. See L for details about usage. - -=item B::CC - -This module writes out C code corresponding to your program's -operations. Unlike the B::C module, which merely stores the -interpreter and its state in a C program, the B::CC module makes a -C program that does not involve the interpreter. As a consequence, -programs translated into C by B::CC can execute faster than normal -interpreted programs. See L for -details about usage. +This module prints a concise (but complete) version of the Perl parse +tree. Its output is more customizable than the one of B::Terse or +B::Debug (and it can emulate them). This module useful for people who +are writing their own back end, or who are learning about the Perl +internals. It's not useful to the average programmer. =item B::Debug @@ -352,12 +233,6 @@ It is useful in debugging and deconstructing other people's code, also as a pretty-printer for your own source. See L for details about usage. -=item B::Disassembler - -This module turns bytecode back into a parse tree. It's not a back -end itself, but rather a component of a back end. It's used by the -I program that comes with the bytecode. - =item B::Lint This module inspects the compiled form of your source code for things @@ -380,19 +255,6 @@ To get a list of the my() variables used in the file myperlprogram: [BROKEN] -=item B::Stackobj - -This module is used by the B::CC module. It's not a back end itself, -but rather a component of a back end. - -=item B::Stash - -This module is used by the L program, which compiles a module -into an executable. B::Stash prints the symbol tables in use by a -program, and is used to prevent B::CC from producing C code for the -B::* and O modules. It's not a back end itself, but rather a -component of a back end. - =item B::Terse This module prints the contents of the parse tree, but without as much @@ -414,19 +276,6 @@ usage. =head1 KNOWN PROBLEMS -The simple C backend currently only saves typeglobs with alphanumeric -names. - -The optimized C backend outputs code for more modules than it should -(e.g., DirHandle). It also has little hope of properly handling -C outside the running subroutine (C is okay). -C currently does not work at all in this backend. -It also creates a huge initialization function that gives -C compilers headaches. Splitting the initialization function gives -better results. Other problems include: unsigned math does not -work correctly; some opcodes are handled incorrectly by default -opcode handling mechanism. - BEGIN{} blocks are executed while compiling your code. Any external state that is initialized in BEGIN{}, such as opening files, initiating database connections etc., do not behave properly. To work around