Penguin
Recent Changes
Blame: perlcompile(1)
EditPageHistoryDiffInfoLikePages
Annotated edit history of perlcompile(1) version 2, including all changes. View license author blame.
Rev Author # Line
1 perry 1 PERLCOMPILE
2 !!!PERLCOMPILE
3 NAME
4 DESCRIPTION
5 Using The Back Ends
6 KNOWN PROBLEMS
7 AUTHOR
8 ----
9 !!NAME
10
11
12 perlcompile - Introduction to the Perl Compiler-Translator
13 !!DESCRIPTION
14
15
16 Perl has always had a compiler: your source is compiled into
17 an internal form (a parse tree) which is then optimized
18 before being run. Since version 5.005, Perl has shipped with
19 a module capable of inspecting the optimized parse tree
20 (B), and this has been used to write many useful
21 utilities, including a module that lets you turn your Perl
22 into C source code that can be compiled into an native
23 executable.
24
25
26 The B module provides access to the parse tree, and
27 other modules (``back ends'') do things with the tree. Some
28 write it out as bytecode, C source code, or a
29 semi-human-readable text. Another traverses the parse tree
30 to build a cross-reference of which subroutines, formats,
31 and variables are used where. Another checks your code for
32 dubious constructs. Yet another back end dumps the parse
33 tree back out as Perl source, acting as a source code
34 beautifier or deobfuscator.
35
36
37 Because its original purpose was to be a way to produce C
38 code corresponding to a Perl program, and in turn a native
39 executable, the B module and its associated back
40 ends are known as ``the compiler'', even though they don't
41 really compile anything. Different parts of the compiler are
42 more accurately a ``translator'', or an ``inspector'', but
43 people want Perl to have a ``compiler option'' not an
44 ``inspector gadget''. What can you do?
45
46
47 This document covers the use of the Perl compiler: which
48 modules it comprises, how to use the most important of the
49 back end modules, what problems there are, and how to work
50 around them.
51
52
53 __Layout__
54
55
56 The compiler back ends are in the B:: hierarchy,
57 and the front-end (the module that you, the user of the
58 compiler, will sometimes interact with) is the O module.
59 Some back ends (e.g., B::C) have programs (e.g.,
60 ''perlcc'') to hide the modules' complexity.
61
62
63 Here are the important back ends to know about, with their
64 status expressed as a number from 0 (outline for later
65 implementation) to 10 (if there's a bug in it, we're very
66 surprised):
67
68
69 B::Bytecode
70
71
72 Stores the parse tree in a machine-independent format,
2 perry 73 suitable for later reloading through the !ByteLoader module.
1 perry 74 Status: 5 (some things work, some things don't, some things
75 are untested).
76
77
78 B::C
79
80
81 Creates a C source file containing code to rebuild the parse
82 tree and resume the interpreter. Status: 6 (many things work
83 adequately, including programs using Tk).
84
85
86 B::CC
87
88
89 Creates a C source file corresponding to the run time code
90 path in the parse tree. This is the closest to a Perl-to-C
91 translator there is, but the code it generates is almost
92 incomprehensible because it translates the parse tree into a
93 giant switch structure that manipulates Perl structures.
94 Eventual goal is to reduce (given sufficient type
95 information in the Perl program) some of the Perl data
96 structure manipulations into manipulations of C-level ints,
97 floats, etc. Status: 5 (some things work, including
98 uncomplicated Tk examples).
99
100
101 B::Lint
102
103
104 Complains if it finds dubious constructs in your source
105 code. Status: 6 (it works adequately, but only has a very
106 limited number of areas that it checks).
107
108
109 B::Deparse
110
111
112 Recreates the Perl source, making an attempt to format it
113 coherently. Status: 8 (it works nicely, but a few obscure
114 things are missing).
115
116
117 B::Xref
118
119
120 Reports on the declaration and use of subroutines and
121 variables. Status: 8 (it works nicely, but still has a few
122 lingering bugs).
123 !!Using The Back Ends
124
125
126 The following sections describe how to use the various
127 compiler back ends. They're presented roughly in order of
128 maturity, so that the most stable and proven back ends are
129 described first, and the most experimental and incomplete
130 back ends are described last.
131
132
133 The O module automatically enabled the __-c__ flag to
134 Perl, which prevents Perl from executing your code once it
135 has been compiled. This is why all the back ends
136 print:
137
138
139 myperlprogram syntax OK
140 before producing any other output.
141
142
143 __The Cross Referencing Back End__
144
145
146 The cross referencing back end (B::Xref) produces a report
147 on your program, breaking down declarations and uses of
148 subroutines and variables (and formats) by file and
149 subroutine. For instance, here's part of the report from the
150 ''pod2man'' program that comes with Perl:
151
152
153 Subroutine clear_noremap
154 Package (lexical)
155 $ready_to_print i1069, 1079
156 Package main
157 $
158 This shows the variables used in the subroutine clear_noremap. The variable $ready_to_print is a ''my()'' (lexical) variable, __i__ntroduced (first declared with ''my()'') on line 1069, and used on line 1079. The variable $ from the main package is used on 1086, and so on.
159
160
161 A line number may be prefixed by a single
162 letter:
163
164
165 i
166
167
168 Lexical variable introduced (declared with ''my()'') for
169 the first time.
170
171
172
173
174 Subroutine or method call.
175
176
177 s
178
179
180 Subroutine defined.
181
182
183 r
184
185
186 Format defined.
187
188
189 The most useful option the cross referencer has is to save
190 the report to a separate file. For instance, to save the
191 report on ''myperlprogram'' to the file
192 ''report'':
193
194
195 $ perl -MO=Xref,-oreport myperlprogram
196
197
198 __The Decompiling Back End__
199
200
201 The Deparse back end turns your Perl source back into Perl
202 source. It can reformat along the way, making it useful as a
203 de-obfuscator. The most basic way to use it is:
204
205
206 $ perl -MO=Deparse myperlprogram
207 You'll notice immediately that Perl has no idea of how to paragraph your code. You'll have to separate chunks of code from each other with newlines by hand. However, watch what it will do with one-liners:
208
209
210 $ perl -MO=Deparse -e '$op=shiftdie
211 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:
212
213
214 $ perl -MO=Deparse,-si2 myperlprogram
215 The __-p__ option adds parentheses where normally they are omitted:
216
217
218 $ perl -MO=Deparse -e 'print
219 See B::Deparse for more information on the formatting options.
220
221
222 __The Lint Back End__
223
224
225 The lint back end (B::Lint) inspects programs for poor
226 style. One programmer's bad style is another programmer's
227 useful tool, so options let you select what is complained
228 about.
229
230
231 To run the style checker across your source
232 code:
233
234
235 $ perl -MO=Lint myperlprogram
236 To disable context checks and undefined subroutines:
237
238
239 $ perl -MO=Lint,-context,-undefined-subs myperlprogram
240 See B::Lint for information on the options.
241
242
243 __The Simple C Back End__
244
245
246 This module saves the internal compiled state of your Perl
247 program to a C source file, which can be turned into a
248 native executable for that particular platform using a C
249 compiler. The resulting program links against the Perl
250 interpreter library, so it will not save you disk space
251 (unless you build Perl with a shared library) or program
252 size. It may, however, save you startup time.
253
254
255 The perlcc tool generates such executables by
256 default.
257
258
259 perlcc myperlprogram.pl
260
261
262 __The Bytecode Back End__
263
264
265 This back end is only useful if you also have a way to load
2 perry 266 and execute the bytecode that it produces. The !ByteLoader
1 perry 267 module provides this functionality.
268
269
270 To turn a Perl program into executable byte code, you can
271 use perlcc with the -b
272 switch:
273
274
275 perlcc -b myperlprogram.pl
276 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).
277
278
279 See __B::Bytecode__ for information on options to control
280 the optimization and nature of the code generated by the
281 Bytecode module.
282
283
284 __The Optimized C Back End__
285
286
287 The optimized C back end will turn your Perl program's run
288 time code-path into an equivalent (but optimized) C program
289 that manipulates the Perl data structures directly. The
290 program will still link against the Perl interpreter
291 library, to allow for ''eval()'', s///e,
292 require, etc.
293
294
295 The perlcc tool generates such executables when
296 using the -opt switch. To compile a Perl program (ending in
297 .pl or .p):
298
299
300 perlcc -opt myperlprogram.pl
301 To produce a shared library from a Perl module (ending in .pm):
302
303
304 perlcc -opt Myperlmodule.pm
305 For more information, see perlcc and B::CC.
306
307
308 B
309
310
311 This module is the introspective (``reflective'' in Java
312 terms) module, which allows a Perl program to inspect its
313 innards. The back end modules all use this module to gain
314 access to the compiled parse tree. You, the user of a back
315 end module, will not need to interact with B.
316
317
318 O
319
320
321 This module is the front-end to the compiler's back ends.
322 Normally called something like this:
323
324
325 $ perl -MO=Deparse myperlprogram
326 This is like saying use O 'Deparse' in your Perl program.
327
328
329 B::Asmdata
330
331
332 This module is used by the B::Assembler module, which is in
333 turn used by the B::Bytecode module, which stores a
334 parse-tree as bytecode for later loading. It's not a back
335 end itself, but rather a component of a back
336 end.
337
338
339 B::Assembler
340
341
342 This module turns a parse-tree into data suitable for
343 storing and later decoding back into a parse-tree. It's not
344 a back end itself, but rather a component of a back end.
345 It's used by the ''assemble'' program that produces
346 bytecode.
347
348
349 B::Bblock
350
351
352 This module is used by the B::CC back end. It walks ``basic
353 blocks''. A basic block is a series of operations which is
354 known to execute from start to finish, with no possibility
355 of branching or halting.
356
357
358 B::Bytecode
359
360
361 This module is a back end that generates bytecode from a
362 program's parse tree. This bytecode is written to a file,
363 from where it can later be reconstructed back into a parse
364 tree. The goal is to do the expensive program compilation
365 once, save the interpreter's state into a file, and then
366 restore the state from the file when the program is to be
367 executed. See ``The Bytecode Back End'' for details about
368 usage.
369
370
371 B::C
372
373
374 This module writes out C code corresponding to the parse
375 tree and other interpreter internal structures. You compile
376 the corresponding C file, and get an executable file that
377 will restore the internal structures and the Perl
378 interpreter will begin running the program. See ``The Simple
379 C Back End'' for details about usage.
380
381
382 B::CC
383
384
385 This module writes out C code corresponding to your
386 program's operations. Unlike the B::C module, which merely
387 stores the interpreter and its state in a C program, the
388 B::CC module makes a C program that does not involve the
389 interpreter. As a consequence, programs translated into C by
390 B::CC can execute faster than normal interpreted programs.
391 See ``The Optimized C Back End'' for details about
392 usage.
393
394
395 B::Debug
396
397
398 This module dumps the Perl parse tree in verbose detail to
399 STDOUT . It's useful for people who are
400 writing their own back end, or who are learning about the
401 Perl internals. It's not useful to the average
402 programmer.
403
404
405 B::Deparse
406
407
408 This module produces Perl source code from the compiled
409 parse tree. It is useful in debugging and deconstructing
410 other people's code, also as a pretty-printer for your own
411 source. See ``The Decompiling Back End'' for details about
412 usage.
413
414
415 B::Disassembler
416
417
418 This module turns bytecode back into a parse tree. It's not
419 a back end itself, but rather a component of a back end.
420 It's used by the ''disassemble'' program that comes with
421 the bytecode.
422
423
424 B::Lint
425
426
427 This module inspects the compiled form of your source code
428 for things which, while some people frown on them, aren't
429 necessarily bad enough to justify a warning. For instance,
430 use of an array in scalar context without explicitly saying
431 scalar(@array) is something that Lint can identify.
432 See ``The Lint Back End'' for details about
433 usage.
434
435
436 B::Showlex
437
438
439 This module prints out the ''my()'' variables used in a
440 function or a file. To get a list of the ''my()''
441 variables used in the subroutine ''mysub()'' defined in
442 the file myperlprogram:
443
444
445 $ perl -MO=Showlex,mysub myperlprogram
446 To get a list of the ''my()'' variables used in the file myperlprogram:
447
448
449 $ perl -MO=Showlex myperlprogram
450 [[ BROKEN ]
451
452
453 B::Stackobj
454
455
456 This module is used by the B::CC module. It's not a back end
457 itself, but rather a component of a back end.
458
459
460 B::Stash
461
462
463 This module is used by the perlcc program, which compiles a
464 module into an executable. B::Stash prints the symbol tables
465 in use by a program, and is used to prevent B::CC from
466 producing C code for the B::* and O modules. It's not a back
467 end itself, but rather a component of a back
468 end.
469
470
471 B::Terse
472
473
474 This module prints the contents of the parse tree, but
475 without as much information as B::Debug. For comparison,
476 print produced 96 lines
477 of output from B::Debug, but only 6 from
478 B::Terse.
479
480
481 This module is useful for people who are writing their own
482 back end, or who are learning about the Perl internals. It's
483 not useful to the average programmer.
484
485
486 B::Xref
487
488
489 This module prints a report on where the variables,
490 subroutines, and formats are defined and used within a
491 program and the modules it loads. See ``The Cross
492 Referencing Back End'' for details about usage.
493 !!KNOWN PROBLEMS
494
495
496 The simple C backend currently only saves typeglobs with
497 alphanumeric names.
498
499
500 The optimized C backend outputs code for more modules than
2 perry 501 it should (e.g., !DirHandle). It also has little hope of
1 perry 502 properly handling goto LABEL outside the running
503 subroutine (goto is okay). goto
504 LABEL currently does not work at all in this backend.
505 It also creates a huge initialization function that gives C
506 compilers headaches. Splitting the initialization function
507 gives better results. Other problems include: unsigned math
508 does not work correctly; some opcodes are handled
509 incorrectly by default opcode handling
510 mechanism.
511
512
513 BEGIN{} blocks are executed while compiling your code. Any
514 external state that is initialized in BEGIN{}, such as
515 opening files, initiating database connections etc., do not
516 behave properly. To work around this, Perl has an INIT{}
517 block that corresponds to code being executed before your
518 program begins running but after your program has finished
519 being compiled. Execution order: BEGIN{}, (possible save of
520 state through compiler back-end), INIT{}, program runs,
521 END{}.
522 !!AUTHOR
523
524
525 This document was originally written by Nathan Torkington,
526 and is now maintained by the perl5-porters mailing list
527 ''perl5-porters@perl.org''.
528 ----
This page is a man page (or other imported legacy content). We are unable to automatically determine the license status of this page.