Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Newer
Older
100644 1409 lines (1097 sloc) 58.187 kb
6df6cc8 @rurban B-C-1.04_13
authored
1 =head1 NAME
2
9b2933c @rurban name change
authored
3 perloptree - The Perl op tree
6df6cc8 @rurban B-C-1.04_13
authored
4
5 =head1 DESCRIPTION
6
7 Various material about the internal Perl compilation representation
8 during parsing and optimization, before the actual execution
92ae860 @rurban Bytecode: save_cq => save_begin+save_init_end: moved push_begin upfro…
authored
9 begins, represented as C<B> objects, the B<"B" op tree>.
6df6cc8 @rurban B-C-1.04_13
authored
10
fbed513 @rurban release 1.04_21
authored
11 The well-known L<perlguts.pod> focuses more on the internal
12 representation of the variables, but not so on the structure, the
13 sequence and the optimization of the basic operations, the ops.
bcf9d85 @rurban B-C-1.04_15
authored
14
fbed513 @rurban release 1.04_21
authored
15 And we have L<perlhack.pod>, which shows e.g. ways to hack into
16 the op tree structure within the debugger. It focuses on getting
17 people to start patching and hacking on the CORE, not
18 understanding or writing compiler backends or optimizations,
92ae860 @rurban Bytecode: save_cq => save_begin+save_init_end: moved push_begin upfro…
authored
19 which the op tree mainly is used for.
6df6cc8 @rurban B-C-1.04_13
authored
20
21 =head1 Brief Summary
22
23 The brief summary is very well described in the
bcf9d85 @rurban B-C-1.04_15
authored
24 L<"Compiled-code"/perlguts#Compiled-code> section of L<perlguts> and
25 at the top of F<op.c>.
6df6cc8 @rurban B-C-1.04_13
authored
26
27 When Perl parses the source code (via Yacc C<perly.y>), the so-called
fbed513 @rurban release 1.04_21
authored
28 op tree, a tree of basic perl OP structs pointing to simple
29 C<pp_>I<opname> functions, is generated bottom-up. Those C<pp_>
30 functions - "PP Code" (for "Push / Pop Code") - have the same uniform
31 API as the XS functions, all arguments and return values are
32 transported on the stack. For example, an C<OP_CONST> op points to
33 the C<pp_const()> function and to an C<SV> containing the constant
34 value. When C<pp_const()> is executed, its job is to push that C<SV>
35 onto the stack.
36
37 OPs are created by the C<newFOO()> functions, which are called
38 from the parser (in F<perly.y>) as the code is parsed. For
39 example the Perl code C<$a + $b * $c> would cause the equivalent
40 of the following to be called (oversimplifying a bit):
bcf9d85 @rurban B-C-1.04_15
authored
41
42 newBINOP(OP_ADD, flags,
43 newSVREF($a),
44 newBINOP(OP_MULTIPLY, flags, newSVREF($b), newSVREF($c))
45 )
46
fbed513 @rurban release 1.04_21
authored
47 See also L<perlhack.pod#Op Trees>
48
92ae860 @rurban Bytecode: save_cq => save_begin+save_init_end: moved push_begin upfro…
authored
49 The simpliest type of an op structure is C<OP>, a L</BASEOP>: this
fbed513 @rurban release 1.04_21
authored
50 has no children. Unary operators, L</UNOP>s, have one child, and
51 this is pointed to by the C<op_first> field. Binary operators
52 (L</BINOP>s) have not only an C<op_first> field but also an
53 C<op_last> field. The most complex type of op is a L</LISTOP>,
54 which has any number of children. In this case, the first child
55 is pointed to by C<op_first> and the last child by
56 C<op_last>. The children in between can be found by iteratively
57 following the C<op_sibling> pointer from the first child to the
58 last.
59
60 There are also two other op types: a L</"PMOP"> holds a regular
61 expression, and has no children, and a L</"LOOP"> may or may not
62 have children. If the C<op_sibling> field is non-zero, it behaves
63 like a C<LISTOP>. To complicate matters, if an C<UNOP> is
64 actually a null op after optimization (see L</"Compile pass 2:
65 context propagation"> below) it will still have children in
66 accordance with its former type.
67
68 The beautiful thing about the op tree representation is that it
69 is a strict 1:1 mapping to the actual source code, which is
70 proven by the L<B::Deparse> module, which generates readable
71 source for the current op tree. Well, almost.
6df6cc8 @rurban B-C-1.04_13
authored
72
bcf9d85 @rurban B-C-1.04_15
authored
73 =head1 The Compiler
74
fbed513 @rurban release 1.04_21
authored
75 Perl's compiler is essentially a 3-pass compiler with interleaved
76 phases:
bcf9d85 @rurban B-C-1.04_15
authored
77
78 1. A bottom-up pass
79 2. A top-down pass
80 3. An execution-order pass
6df6cc8 @rurban B-C-1.04_13
authored
81
bcf9d85 @rurban B-C-1.04_15
authored
82 =head2 Compile pass 1: check routines and constant folding
6df6cc8 @rurban B-C-1.04_13
authored
83
fbed513 @rurban release 1.04_21
authored
84 The bottom-up pass is represented by all the C<"newOP"> routines
85 and the C<ck_> routines. The bottom-upness is actually driven by
86 F<yacc>. So at the point that a C<ck_> routine fires, we have no
87 idea what the context is, either upward in the syntax tree, or
88 either forward or backward in the execution order. The bottom-up
89 parser builds that part of the execution order it knows about,
90 but if you follow the "next" links around, you'll find it's
91 actually a closed loop through the top level node.
92
93 So when creating the ops in the first step, still bottom-up, for
94 each op a check function (C<ck_ ()>) is called, which which
95 theroretically may destructively modify the whole tree, but
96 because it knows almost nothing, it mostly just nullifies the
97 current op. Or it might set the L</op_next> pointer. See
bcf9d85 @rurban B-C-1.04_15
authored
98 L</"Check Functions"> for more.
99
fbed513 @rurban release 1.04_21
authored
100 Also, the subsequent constant folding routine C<fold_constants()>
4ace4a5 @rurban improve perloptree.pod
authored
101 may fold certain arithmetic op sequences. See L</"Constant Folding">
102 for more.
6df6cc8 @rurban B-C-1.04_13
authored
103
104 =head2 Compile pass 2: context propagation
105
fbed513 @rurban release 1.04_21
authored
106 The context determines the type of the return value. When a
107 context for a part of compile tree is known, it is propagated
6df6cc8 @rurban B-C-1.04_13
authored
108 down through the tree. At this time the context can have 5 values
fbed513 @rurban release 1.04_21
authored
109 (instead of 2 for runtime context): C<void>, C<boolean>,
110 C<scalar>, C<list>, and C<lvalue>. In contrast with the pass 1
111 this pass is processed from top to bottom: a node's context
112 determines the context for its children.
113
114 Whenever the bottom-up parser gets to a node that supplies
115 context to its components, it invokes that portion of the
116 top-down pass that applies to that part of the subtree (and marks
117 the top node as processed, so if a node further up supplies
118 context, it doesn't have to take the plunge again). As a
119 particular subcase of this, as the new node is built, it takes
120 all the closed execution loops of its subcomponents and links
121 them into a new closed loop for the higher level node. But it's
122 still not the real execution order.
bcf9d85 @rurban B-C-1.04_15
authored
123
124 I<Todo: Sample where this context flag is stored>
6df6cc8 @rurban B-C-1.04_13
authored
125
126 Additional context-dependent optimizations are performed at this
127 time. Since at this moment the compile tree contains back-references
128 (via "thread" pointers), nodes cannot be C<free()>d now. To allow
129 optimized-away nodes at this stage, such nodes are C<null()>ified
bcf9d85 @rurban B-C-1.04_15
authored
130 instead of C<free()>'ing (i.e. their type is changed to C<OP_NULL>).
6df6cc8 @rurban B-C-1.04_13
authored
131
132 =head2 Compile pass 3: peephole optimization
133
fbed513 @rurban release 1.04_21
authored
134 The actual execution order is not known till we get a grammar
135 reduction to a top-level unit like a subroutine or file that will
136 be called by "name" rather than via a "next" pointer. At that
137 point, we can call into peep() to do that code's portion of the
138 3rd pass. It has to be recursive, but it's recursive on basic
139 blocks, not on tree nodes.
bcf9d85 @rurban B-C-1.04_15
authored
140
fbed513 @rurban release 1.04_21
authored
141 So finally, when the full parse tree is generated, the "peephole
142 optimizer" C<peep()> is running. This pass is neither top-down
143 or bottom-up, but in the execution order (with additional
144 complications for conditionals).
6df6cc8 @rurban B-C-1.04_13
authored
145
146 This examines each op in the tree and attempts to determine "local"
147 optimizations by "thinking ahead" one or two ops and seeing if
148 multiple operations can be combined into one (by nullifying and
149 re-ordering the next pointers).
150
fbed513 @rurban release 1.04_21
authored
151 It also checks for lexical issues such as the effect of C<use
152 strict> on bareword constants. Note that since the last walk the
153 early sibling pointers for recursive (bottom-up) meta-inspection
154 are useless, the final exec order is guaranteed by the next and
155 flags fields.
6df6cc8 @rurban B-C-1.04_13
authored
156
157 =head1 basic vs exec order
158
fbed513 @rurban release 1.04_21
authored
159 The highly recursive Yacc parser generates the initial op tree in
160 B<basic> order. To save memory and run-time the final execution
161 order of the ops in sequential order is not copied around, just
162 the next pointers are rehooked in C<Perl_linklist()> to the
163 so-called B<exec> order. So the exec walk through the
164 linked-list of ops is not too cache-friendly.
4665e77 @rurban added ByteCache, ByteCode56, updated Debug, fixed tests
authored
165
fbed513 @rurban release 1.04_21
authored
166 In detail C<Perl_linklist()> traverses the op tree, and sets
167 op-next pointers to give the execution order for that op
168 tree. op-sibling pointers are rarely unneeded after that.
bcf9d85 @rurban B-C-1.04_15
authored
169
fbed513 @rurban release 1.04_21
authored
170 Walkers can run in "basic" or "exec" order. "basic" is useful
171 for the memory layout, it contains the history, "exec" is more
172 useful to understand the logic and program flow. The
173 L</B::Bytecode> section has an extensive example about the order.
6df6cc8 @rurban B-C-1.04_13
authored
174
175 =head1 OP Structure and Inheritance
176
177 The basic C<struct op> looks basically like
fbed513 @rurban release 1.04_21
authored
178
6df6cc8 @rurban B-C-1.04_13
authored
179 C<{ OP* op_next, OP* op_sibling, OP* op_ppaddr, ..., int op_flags, int op_private } OP;>
fbed513 @rurban release 1.04_21
authored
180
6df6cc8 @rurban B-C-1.04_13
authored
181 See L</BASEOP> below.
182
fbed513 @rurban release 1.04_21
authored
183 Each op is defined in size, arguments, return values, class and
184 more in the F<opcode.pl> table. (See L</"OP Class Declarations in
185 opcode.pl"> below.)
6df6cc8 @rurban B-C-1.04_13
authored
186
fbed513 @rurban release 1.04_21
authored
187 The class of an OP determines its size and the number of
188 children. But the number and type of arguments is not so easy to
189 declare as in C. F<opcode.pl> tries to declare some XS-prototype
190 like arguments, but in lisp we would say most ops are "special"
9920f38 @rurban -DF print stringified sv and op flags
authored
191 functions, context-dependent, with special parsing and precedence rules.
6df6cc8 @rurban B-C-1.04_13
authored
192
fbed513 @rurban release 1.04_21
authored
193 F<B.pm> L<http://search.cpan.org/perldoc?B> contains these
194 classes and inheritance:
6df6cc8 @rurban B-C-1.04_13
authored
195
196 @B::OP::ISA = 'B::OBJECT';
197 @B::UNOP::ISA = 'B::OP';
198 @B::BINOP::ISA = 'B::UNOP';
199 @B::LOGOP::ISA = 'B::UNOP';
200 @B::LISTOP::ISA = 'B::BINOP';
201 @B::SVOP::ISA = 'B::OP';
202 @B::PADOP::ISA = 'B::OP';
203 @B::PVOP::ISA = 'B::OP';
204 @B::LOOP::ISA = 'B::LISTOP';
205 @B::PMOP::ISA = 'B::LISTOP';
206 @B::COP::ISA = 'B::OP';
207 @B::SPECIAL::ISA = 'B::OBJECT';
208 @B::optype = qw(OP UNOP BINOP LOGOP LISTOP PMOP SVOP PADOP PVOP LOOP COP);
209
bcf9d85 @rurban B-C-1.04_15
authored
210 I<TODO: ascii graph from perlguts>
211
9920f38 @rurban -DF print stringified sv and op flags
authored
212 F<op.h> L<http://search.cpan.org/src/JESSE/perl-5.12.1/op.h>
213 contains all the gory details. Let's check it out:
6df6cc8 @rurban B-C-1.04_13
authored
214
215 =head2 OP Class Declarations in opcode.pl
216
fbed513 @rurban release 1.04_21
authored
217 The full list of op declarations is defined as C<DATA> in
218 F<opcode.pl>. It defines the class, the name, some flags, and
219 the argument types, the so-called "operands". C<make regen> (via
220 F<regen.pl>) recreates out of this DATA table the files
221 F<opcode.h>, F<opnames.h>, F<pp_proto.h> and F<pp.sym>.
6df6cc8 @rurban B-C-1.04_13
authored
222
223 The class signifiers in F<opcode.pl> are:
224
225 baseop - 0 unop - 1 binop - 2
226 logop - | listop - @ pmop - /
227 padop/svop - $ padop - # (unused) loop - {
228 baseop/unop - % loopexop - } filestatop - -
229 pvop/svop - " cop - ;
230
231 Other options within F<opcode.pl> are:
232
233 needs stack mark - m
234 needs constant folding - f
235 produces a scalar - s
236 produces an integer - i
237 needs a target - t
238 target can be in a pad - T
239 has a corresponding integer version - I
240 has side effects - d
241 uses $_ if no argument given - u
242
243 Values for the operands are:
244
245 scalar - S list - L array - A
246 hash - H sub (CV) - C file - F
247 socket - Fs filetest - F- reference - R
248 "?" denotes an optional operand.
249
250 =head2 BASEOP
251
fbed513 @rurban release 1.04_21
authored
252 All op classes have a single character signifier for easier
253 definition in F<opcode.pl>. The BASEOP class signifier is B<0>,
254 for no children.
6df6cc8 @rurban B-C-1.04_13
authored
255
fbed513 @rurban release 1.04_21
authored
256 Below are the BASEOP fields, which reflect the object C<B::OP>,
257 since Perl 5.10. These are shared for all op classes. The parts
258 after C<op_type> and before C<op_flags> changed during history.
6df6cc8 @rurban B-C-1.04_13
authored
259
bcf9d85 @rurban B-C-1.04_15
authored
260 =over
261
262 =item op_next
263
264 Pointer to next op to execute after this one.
265
fbed513 @rurban release 1.04_21
authored
266 Top level pre-grafted op points to first op, but this is replaced
267 when op is grafted in, when this op will point to the real next
268 op, and the new parent takes over role of remembering the
269 starting op. I<Now, who wrote this prose? Anyway, that is why it
270 is called guts.>
bcf9d85 @rurban B-C-1.04_15
authored
271
272 =item op_sibling
273
274 Pointer to connect the children's list.
275
fbed513 @rurban release 1.04_21
authored
276 The first child is L</op_first>, the last is L</op_last>, and the
277 children in between are interconnected by op_sibling. This is at
278 run-time only used for L</LISTOP>s.
bcf9d85 @rurban B-C-1.04_15
authored
279
280 So why is it in the BASEOP struct carried around for every op?
281
fbed513 @rurban release 1.04_21
authored
282 Because of the complicated Yacc parsing and later optimization
283 order as explained in L<"Compile pass 1: check routines and
284 constant folding"> the L</op_next> pointers are not enough, so
285 op_sibling's are required. The final and fast execution order by
286 just following the op_next chain is expensive to calculate.
bcf9d85 @rurban B-C-1.04_15
authored
287
fbed513 @rurban release 1.04_21
authored
288 See
289 http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2006-09/msg00082.html
4665e77 @rurban added ByteCache, ByteCode56, updated Debug, fixed tests
authored
290 for a 20% space-reduction patch to get rid of it at run-time.
291
bcf9d85 @rurban B-C-1.04_15
authored
292 =item op_ppaddr
293
294 Pointer to current ppcode's function.
295 The so called "opcode".
296
297 =item op_madprop
298
fbed513 @rurban release 1.04_21
authored
299 Pointer to the MADPROP struct. Only with -DMAD, and since
300 5.10. See L</MAD> (Misc Attribute Decoration) below.
bcf9d85 @rurban B-C-1.04_15
authored
301
302 =item op_targ
303
fbed513 @rurban release 1.04_21
authored
304 PADOFFSET to "unnamed" op targets/GVs/constants, wasting no
305 SV. Has for some op's also a different meaning.
bcf9d85 @rurban B-C-1.04_15
authored
306
307 =item op_type
308
309 The type of the operation.
310
fbed513 @rurban release 1.04_21
authored
311 Since 5.10 we have the next five fields added, which replace
312 C<U16 op_seq>.
bcf9d85 @rurban B-C-1.04_15
authored
313
314 =item op_opt
315
316 "optimized"
317
318 Whether or not the op has been optimised by the peephole optimiser.
319
fbed513 @rurban release 1.04_21
authored
320 See the comments in C<S_clear_yystack()> in F<perly.c> for more
321 details on the following three flags. They are just for freeing
322 temporary ops on the stack. But we might have statically
323 allocated op in the data segment, esp. with the perl compiler's
324 L<B::C> module. Then we are not allowed to free those static
325 ops. For a short time, from 5.9.0 until 5.9.4, until the B::C
326 module was removed from CORE, we had another field here for this
327 reason: B<op_static>. On 1 it didn't free the static op. Before
328 5.9.0 the L</op_seq> field was used with the magic value B<-1> to
329 indicate a static op, not to be freed. Note: Trying to free a
330 static struct is considered harmful.
bcf9d85 @rurban B-C-1.04_15
authored
331
332 =item op_latefree
333
fbed513 @rurban release 1.04_21
authored
334 Tell C<op_free()> to clear this op (and free any kids) but not
335 yet deallocate the struct. This means that the op may be safely
336 C<op_free()>d multiple times.
bcf9d85 @rurban B-C-1.04_15
authored
337
fbed513 @rurban release 1.04_21
authored
338 On static ops you just set this to B<1> and after the first
339 C<op_free()> the C<op_latefreed> is automatically set and further
340 C<op_free()> called are just ignored.
bcf9d85 @rurban B-C-1.04_15
authored
341
342 =item op_latefreed
343
fbed513 @rurban release 1.04_21
authored
344 If 1, an C<op_latefree> op has been C<op_free()>d.
bcf9d85 @rurban B-C-1.04_15
authored
345
346 =item op_attached
347
fbed513 @rurban release 1.04_21
authored
348 This op (sub)tree has been attached to the CV C<PL_compcv> so it
349 doesn't need to be free'd.
bcf9d85 @rurban B-C-1.04_15
authored
350
351 =item op_spare
6df6cc8 @rurban B-C-1.04_13
authored
352
bcf9d85 @rurban B-C-1.04_15
authored
353 Three spare bits in this bitfield above. At least they survived 5.10.
6df6cc8 @rurban B-C-1.04_13
authored
354
355
bcf9d85 @rurban B-C-1.04_15
authored
356 Those last two fields have been in all perls:
6df6cc8 @rurban B-C-1.04_13
authored
357
bcf9d85 @rurban B-C-1.04_15
authored
358 =item op_flags
6df6cc8 @rurban B-C-1.04_13
authored
359
bcf9d85 @rurban B-C-1.04_15
authored
360 Flags common to all operations.
361 See C<OPf_*> in F<op.h>, or more verbose in L<B::Flags> or F<dump.c>
6df6cc8 @rurban B-C-1.04_13
authored
362
bcf9d85 @rurban B-C-1.04_15
authored
363 =item op_private
6df6cc8 @rurban B-C-1.04_13
authored
364
fbed513 @rurban release 1.04_21
authored
365 Flags peculiar to a particular operation (BUT, by default, set to
366 the number of children until the operation is privatized by a
367 check routine, which may or may not check number of children).
6df6cc8 @rurban B-C-1.04_13
authored
368
fbed513 @rurban release 1.04_21
authored
369 This flag is normally used to hold op specific context hints,
370 such as C<HINT_INTEGER>. This flag is directly attached to each
371 relevant op in the subtree of the context. Note that there's no
372 general context or class pointer for each op, a typical
373 functional language usually holds this in the ops arguments. So
374 we are limited to max 32 lexical pragma hints or less. See
375 L</Lexical Pragmas>.
6df6cc8 @rurban B-C-1.04_13
authored
376
bcf9d85 @rurban B-C-1.04_15
authored
377 =back
378
379 The exact op.h L</BASEOP> history for the parts after C<op_type> and
6df6cc8 @rurban B-C-1.04_13
authored
380 before C<op_flags> is:
381
382 <=5.8: U16 op_seq;
bcf9d85 @rurban B-C-1.04_15
authored
383 5.9.4: unsigned op_opt:1; unsigned op_static:1; unsigned op_spare:5;
6df6cc8 @rurban B-C-1.04_13
authored
384 >=5.10: unsigned op_opt:1; unsigned op_latefree:1; unsigned op_latefreed:1;
385 unsigned op_attached:1; unsigned op_spare:3;
386
bcf9d85 @rurban B-C-1.04_15
authored
387 The L</BASEOP> class signifier is B<0>, for no children.
6df6cc8 @rurban B-C-1.04_13
authored
388 The full list of all BASEOP's is:
389
390 $ perl -F"/\cI+/" -ane 'print if $F[3] =~ /0$/' opcode.pl
391 null null operation ck_null 0
392 stub stub ck_null 0
393 pushmark pushmark ck_null s0
394 wantarray wantarray ck_null is0
395 padsv private variable ck_null ds0
396 padav private array ck_null d0
397 padhv private hash ck_null d0
398 padany private value ck_null d0
399 sassign scalar assignment ck_sassign s0
400 unstack iteration finalizer ck_null s0
401 enter block entry ck_null 0
402 iter foreach loop iterator ck_null 0
403 break break ck_null 0
404 continue continue ck_null 0
405 fork fork ck_null ist0
406 wait wait ck_null isT0
407 getppid getppid ck_null isT0
408 time time ck_null isT0
409 tms times ck_null 0
410 ghostent gethostent ck_null 0
411 gnetent getnetent ck_null 0
412 gprotoent getprotoent ck_null 0
413 gservent getservent ck_null 0
414 ehostent endhostent ck_null is0
415 enetent endnetent ck_null is0
416 eprotoent endprotoent ck_null is0
417 eservent endservent ck_null is0
418 gpwent getpwent ck_null 0
419 spwent setpwent ck_null is0
420 epwent endpwent ck_null is0
421 ggrent getgrent ck_null 0
422 sgrent setgrent ck_null is0
423 egrent endgrent ck_null is0
424 getlogin getlogin ck_null st0
425 custom unknown custom operator ck_null 0
426
9920f38 @rurban -DF print stringified sv and op flags
authored
427 =head3 null
428
429 null ops are skipped during the runloop, and are created by the peephole optimizer.
430
6df6cc8 @rurban B-C-1.04_13
authored
431 =head2 UNOP
432
fbed513 @rurban release 1.04_21
authored
433 The unary op class signifier is B<1>, for one child, pointed to
434 by C<op_first>.
6df6cc8 @rurban B-C-1.04_13
authored
435
436 struct unop {
437 BASEOP
438 OP * op_first;
439 }
440
441 $ perl -F"/\cI+/" -ane 'print if $F[3] =~ /1$/' opcode.pl
442 rv2gv ref-to-glob cast ck_rvconst ds1
443 rv2sv scalar dereference ck_rvconst ds1
444 av2arylen array length ck_null is1
445 rv2cv subroutine dereference ck_rvconst d1
446 refgen reference constructor ck_spair m1 L
447 srefgen single ref constructor ck_null fs1 S
448 regcmaybe regexp internal guard ck_fun s1 S
449 regcreset regexp internal reset ck_fun s1 S
450 preinc preincrement (++) ck_lfun dIs1 S
451 i_preinc integer preincrement (++) ck_lfun dis1 S
452 predec predecrement (--) ck_lfun dIs1 S
453 i_predec integer predecrement (--) ck_lfun dis1 S
454 postinc postincrement (++) ck_lfun dIst1 S
455 i_postinc integer postincrement (++) ck_lfun disT1 S
456 postdec postdecrement (--) ck_lfun dIst1 S
457 i_postdec integer postdecrement (--) ck_lfun disT1 S
458 negate negation (-) ck_null Ifst1 S
459 i_negate integer negation (-) ck_null ifsT1 S
460 not not ck_null ifs1 S
461 complement 1's complement (~) ck_bitop fst1 S
462 rv2av array dereference ck_rvconst dt1
463 rv2hv hash dereference ck_rvconst dt1
464 flip range (or flip) ck_null 1 S S
465 flop range (or flop) ck_null 1
466 method method lookup ck_method d1
467 entersub subroutine entry ck_subr dmt1 L
468 leavesub subroutine exit ck_null 1
469 leavesublv lvalue subroutine return ck_null 1
470 leavegiven leave given block ck_null 1
471 leavewhen leave when block ck_null 1
472 leavewrite write exit ck_null 1
473 dofile do "file" ck_fun d1 S
474 leaveeval eval "string" exit ck_null 1 S
475 #evalonce eval constant string ck_null d1 S
476
477 =head2 BINOP
478
bcf9d85 @rurban B-C-1.04_15
authored
479 The BINOP class signifier is B<2>, for two children, pointed to by
6df6cc8 @rurban B-C-1.04_13
authored
480 C<op_first> and C<op_last>.
481
482 struct binop {
483 BASEOP
484 OP * op_first;
485 OP * op_last;
486 }
487
488 $ perl -F"/\cI+/" -ane 'print if $F[3] =~ /2$/' opcode.pl
489 gelem glob elem ck_null d2 S S
490 aassign list assignment ck_null t2 L L
491 pow exponentiation (**) ck_null fsT2 S S
492 multiply multiplication (*) ck_null IfsT2 S S
493 i_multiply integer multiplication (*) ck_null ifsT2 S S
494 divide division (/) ck_null IfsT2 S S
495 i_divide integer division (/) ck_null ifsT2 S S
496 modulo modulus (%) ck_null IifsT2 S S
497 i_modulo integer modulus (%) ck_null ifsT2 S S
498 repeat repeat (x) ck_repeat mt2 L S
499 add addition (+) ck_null IfsT2 S S
500 i_add integer addition (+) ck_null ifsT2 S S
501 subtract subtraction (-) ck_null IfsT2 S S
502 i_subtract integer subtraction (-) ck_null ifsT2 S S
503 concat concatenation (.) or string ck_concat fsT2 S S
504 left_shift left bitshift (<<) ck_bitop fsT2 S S
505 right_shift right bitshift (>>) ck_bitop fsT2 S S
506 lt numeric lt (<) ck_null Iifs2 S S
507 i_lt integer lt (<) ck_null ifs2 S S
508 gt numeric gt (>) ck_null Iifs2 S S
509 i_gt integer gt (>) ck_null ifs2 S S
510 le numeric le (<=) ck_null Iifs2 S S
511 i_le integer le (<=) ck_null ifs2 S S
512 ge numeric ge (>=) ck_null Iifs2 S S
513 i_ge integer ge (>=) ck_null ifs2 S S
514 eq numeric eq (==) ck_null Iifs2 S S
515 i_eq integer eq (==) ck_null ifs2 S S
516 ne numeric ne (!=) ck_null Iifs2 S S
517 i_ne integer ne (!=) ck_null ifs2 S S
518 ncmp numeric comparison (<=>)ck_null Iifst2 S S
519 i_ncmp integer comparison (<=>)ck_null ifst2 S S
520 slt string lt ck_null ifs2 S S
521 sgt string gt ck_null ifs2 S S
522 sle string le ck_null ifs2 S S
523 sge string ge ck_null ifs2 S S
524 seq string eq ck_null ifs2 S S
525 sne string ne ck_null ifs2 S S
526 scmp string comparison (cmp) ck_null ifst2 S S
527 bit_and bitwise and (&) ck_bitop fst2 S S
528 bit_xor bitwise xor (^) ck_bitop fst2 S S
529 bit_or bitwise or (|) ck_bitop fst2 S S
530 smartmatch smart match ck_smartmatch s2
531 aelem array element ck_null s2 A S
532 helem hash element ck_null s2 H S
533 lslice list slice ck_null 2 H L L
534 xor logical xor ck_null fs2 S S
535 leaveloop loop exit ck_null 2
536
537 =head2 LOGOP
538
bcf9d85 @rurban B-C-1.04_15
authored
539 The LOGOP class signifier is B<|>.
6df6cc8 @rurban B-C-1.04_13
authored
540
bcf9d85 @rurban B-C-1.04_15
authored
541 A LOGOP has the same structure as a L</BINOP>, two children, just the
6df6cc8 @rurban B-C-1.04_13
authored
542 second field has another name C<op_other> instead of C<op_last>.
543 But as you see on the list below, the two arguments as above are optional and
544 not strictly required.
545
546 struct logop {
547 BASEOP
548 OP * op_first;
549 OP * op_other;
550 };
551
552 $ perl -F"/\cI+/" -ane 'print if $F[3] =~ /\|$/' opcode.pl
553 regcomp regexp compilation ck_null s| S
554 substcont substitution iterator ck_null dis|
555 grepwhile grep iterator ck_null dt|
556 mapwhile map iterator ck_null dt|
557 range flipflop ck_null | S S
558 and logical and (&&) ck_null |
559 or logical or (||) ck_null |
560 dor defined or (//) ck_null |
561 cond_expr conditional expression ck_null d|
562 andassign logical and assignment (&&=) ck_null s|
563 orassign logical or assignment (||=) ck_null s|
564 dorassign defined or assignment (//=) ck_null s|
565 entergiven given() ck_null d|
566 enterwhen when() ck_null d|
567 entertry eval {block} ck_null |
568 once once ck_null |
569
8f85f24 @rurban perloptree.pod: added and, cond_expr
authored
570 =head3 and
571
572 Checks for falseness on the first argument on the stack.
573 If false, returns immediately, keeping the false value on the stack.
574 If true pops the stack, and returns the op at C<op_other>.
575
576 Note: B<and> is also used for a simple B<if> without B<else>/B<elsif>.
577 The general B<if> is done with L<cond_expr>.
578
579 =head3 cond_expr
580
581 Checks for trueness on the first argument on the stack.
582 If true returns the op at C<op_other>, if false C<op_next>.
583
584 Note: A simple B<if> without else is done by L<and>.
585
6df6cc8 @rurban B-C-1.04_13
authored
586 =head2 LISTOP
587
bcf9d85 @rurban B-C-1.04_15
authored
588 The LISTOP class signifier is B<@>.
6df6cc8 @rurban B-C-1.04_13
authored
589
590 struct listop {
591 BASEOP
592 OP * op_first;
593 OP * op_last;
594 };
595
596 This is most complex type, it may have any number of children. The
597 first child is pointed to by C<op_first> and the last child by
598 C<op_last>. The children in between can be found by iteratively
599 following the C<op_sibling> pointer from the first child to the last.
600
fbed513 @rurban release 1.04_21
authored
601 At all 99 ops from 366 are LISTOP's. This is the least
602 restrictive format, that's why.
6df6cc8 @rurban B-C-1.04_13
authored
603
604 $ perl -F"/\cI+/" -ane 'print if $F[3] =~ /\@$/' opcode.pl
605 bless bless ck_fun s@ S S?
606 glob glob ck_glob t@ S?
607 stringify string ck_fun fsT@ S
608 atan2 atan2 ck_fun fsT@ S S
609 substr substr ck_substr st@ S S S? S?
610 vec vec ck_fun ist@ S S S
611 index index ck_index isT@ S S S?
612 rindex rindex ck_index isT@ S S S?
613 sprintf sprintf ck_fun fmst@ S L
614 formline formline ck_fun ms@ S L
615 crypt crypt ck_fun fsT@ S S
616 aslice array slice ck_null m@ A L
617 hslice hash slice ck_null m@ H L
618 unpack unpack ck_unpack @ S S?
619 pack pack ck_fun mst@ S L
620 split split ck_split t@ S S S
621 join join or string ck_join mst@ S L
622 list list ck_null m@ L
623 anonlist anonymous list ([]) ck_fun ms@ L
624 anonhash anonymous hash ({}) ck_fun ms@ L
625 splice splice ck_fun m@ A S? S? L
626 ... and so on, until
627 syscall syscall ck_fun imst@ S L
628
629 =head2 PMOP
630
bcf9d85 @rurban B-C-1.04_15
authored
631 The PMOP "pattern matching" class signifier is B</> for matching.
632 It inherits from the L</LISTOP>.
6df6cc8 @rurban B-C-1.04_13
authored
633
fbed513 @rurban release 1.04_21
authored
634 The internal struct changed completely with 5.10, as the
635 underlying engine. Starting with 5.11 the PMOP can even hold
636 native L<"REGEX"/perlguts#REGEX> objects, not just SV's. So you
637 have to use the C<PM> macros to stay compatible.
6df6cc8 @rurban B-C-1.04_13
authored
638
639 Below is the current C<struct pmop>. You will not like it.
640
641 struct pmop {
642 BASEOP
643 OP * op_first;
644 OP * op_last;
645 #ifdef USE_ITHREADS
646 IV op_pmoffset;
647 #else
648 REGEXP * op_pmregexp; /* compiled expression */
649 #endif
650 U32 op_pmflags;
651 union {
652 OP * op_pmreplroot; /* For OP_SUBST */
653 #ifdef USE_ITHREADS
654 PADOFFSET op_pmtargetoff; /* For OP_PUSHRE */
655 #else
656 GV * op_pmtargetgv;
657 #endif
658 } op_pmreplrootu;
659 union {
660 OP * op_pmreplstart; /* Only used in OP_SUBST */
661 #ifdef USE_ITHREADS
662 char * op_pmstashpv; /* Only used in OP_MATCH, with PMf_ONCE set */
663 #else
664 HV * op_pmstash;
665 #endif
666 } op_pmstashstartu;
667 };
668
669 Before we had no union, but a C<op_pmnext>, which never worked.
670 Maybe because of the typo in the comment.
bcf9d85 @rurban B-C-1.04_15
authored
671
6df6cc8 @rurban B-C-1.04_13
authored
672 The old struct (up to 5.8.x) was as simple as:
673
674 struct pmop {
675 BASEOP
676 OP * op_first;
677 OP * op_last;
678 U32 op_children;
679 OP * op_pmreplroot;
680 OP * op_pmreplstart;
681 PMOP * op_pmnext; /* list of all scanpats */
682 REGEXP * op_pmregexp; /* compiled expression */
683 U16 op_pmflags;
684 U16 op_pmpermflags;
685 U8 op_pmdynflags;
686 }
bcf9d85 @rurban B-C-1.04_15
authored
687
6df6cc8 @rurban B-C-1.04_13
authored
688 So C<op_pmnext>, C<op_pmpermflags> and C<op_pmdynflags> are gone.
bcf9d85 @rurban B-C-1.04_15
authored
689 The C<op_pmflags> are not the whole deal, there's also C<op_pmregexp.extflags>
690 - interestingly called C<B::PMOP::reflags> in B - for the new features.
691 This is btw. the only inconsistency in the B mapping.
6df6cc8 @rurban B-C-1.04_13
authored
692
693 $ perl -F"/\cI+/" -ane 'print if $F[3] =~ /\/$/' opcode.pl
694 pushre push regexp ck_null d/
695 match pattern match (m//) ck_match d/
696 qr pattern quote (qr//) ck_match s/
697 subst substitution (s///) ck_match dis/ S
698
699 =head2 SVOP
700
701 The SVOP class is very special, and can even change dynamically.
702 Whole SV's are costly and are now just used as GV or RV.
703 The SVOP has no special signifier, as there are different subclasses.
bcf9d85 @rurban B-C-1.04_15
authored
704 See L</"SVOP_OR_PADOP">, L</"PVOP_OR_SVOP"> and L</"FILESTATOP">.
6df6cc8 @rurban B-C-1.04_13
authored
705
706 A SVOP holds a SV and is in case of an FILESTATOP the GV for the
bcf9d85 @rurban B-C-1.04_15
authored
707 filehandle argument, and in case of C<trans> (a L</PVOP>) with utf8 a
6df6cc8 @rurban B-C-1.04_13
authored
708 reference to a swash (i.e., an RV pointing to an HV).
709
710 struct svop {
711 BASEOP
712 SV * op_sv;
713 };
714
bcf9d85 @rurban B-C-1.04_15
authored
715 Most old SVOP's were changed to L</PADOP>'s when threading was introduced, to
6df6cc8 @rurban B-C-1.04_13
authored
716 privatize the global SV area to thread-local scratchpads.
717
718 =head3 SVOP_OR_PADOP
719
bcf9d85 @rurban B-C-1.04_15
authored
720 The op C<aelemfast> is either a L<PADOP> with threading and a simple L<SVOP> without.
6df6cc8 @rurban B-C-1.04_13
authored
721 This is thanksfully known at compile-time.
722
723 aelemfast constant array element ck_null s$ A S
724
725 =head3 PVOP_OR_SVOP
726
727 The only op here is C<trans>, where the class is dynamically defined,
bcf9d85 @rurban B-C-1.04_15
authored
728 dependent on the utf8 settings in the L</op_private> hints.
6df6cc8 @rurban B-C-1.04_13
authored
729
730 case OA_PVOP_OR_SVOP:
731 return (o->op_private & (OPpTRANS_TO_UTF|OPpTRANS_FROM_UTF))
732 ? OPc_SVOP : OPc_PVOP;
733
734 trans transliteration (tr///) ck_null is" S
735
bcf9d85 @rurban B-C-1.04_15
authored
736 Character translations (C<tr///>) are usually a L<PVOP>, keeping a pointer
6df6cc8 @rurban B-C-1.04_13
authored
737 to a table of shorts used to look up translations. Under utf8,
bcf9d85 @rurban B-C-1.04_15
authored
738 however, a simple table isn't practical; instead, the OP is an L</SVOP>,
855afd1 @rurban B-C-1.04_20
authored
739 and the SV is a reference to a B<swash>, i.e. a RV pointing to an HV.
6df6cc8 @rurban B-C-1.04_13
authored
740
741 =head2 PADOP
742
bcf9d85 @rurban B-C-1.04_15
authored
743 The PADOP class signifier is B<$> for temp. scalars.
6df6cc8 @rurban B-C-1.04_13
authored
744
855afd1 @rurban B-C-1.04_20
authored
745 A new C<PADOP> creates a new temporary scratchpad, an PADLIST array.
6df6cc8 @rurban B-C-1.04_13
authored
746 C<padop->op_padix = pad_alloc(type, SVs_PADTMP);>
747 C<SVs_PADTMP> are targets/GVs/constants with undef names.
748
749 A C<PADLIST> scratchpad is a special context stack, a array-of-array data structure
fbed513 @rurban release 1.04_21
authored
750 attached to a CV (i.e. a sub), to store lexical variables and opcode temporary and
6df6cc8 @rurban B-C-1.04_13
authored
751 per-thread values. See L<perlguts/Scratchpads>.
752
753 Only my/our variable (C<SVs_PADMY>/C<SVs_PADOUR>) slots get valid names.
754 The rest are op targets/GVs/constants which are statically allocated
755 or resolved at compile time. These don't have names by which they
756 can be looked up from Perl code at run time through eval "" like
757 my/our variables can be. Since they can't be looked up by "name"
758 but only by their index allocated at compile time (which is usually
759 in C<op_targ>), wasting a name SV for them doesn't make sense.
760
761 struct padop {
762 BASEOP
763 PADOFFSET op_padix;
764 };
765
766 $ perl -F"/\cI+/" -ane 'print if $F[3] =~ /\$$/' opcode.pl
767 const constant item ck_svconst s$
768 gvsv scalar variable ck_null ds$
769 gv glob value ck_null ds$
770 anoncode anonymous subroutine ck_anoncode $
771 rcatline append I/O operator ck_null t$
772 aelemfast constant array element ck_null s$ A S
773 method_named method with known name ck_null d$
774 hintseval eval hints ck_svconst s$
775
776 =head2 PVOP
777
778 This is a simple unary op, holding a string.
779 The only PVOP is C<trans> op for L<tr///>.
780 See above at L</PVOP_OR_SVOP> for the dynamic nature of trans with utf8.
781
782 The PVOP class signifier is C<"> for strings.
783
784 struct pvop {
785 BASEOP
786 char * op_pv;
787 };
788
789 $ perl -F"/\cI+/" -ane 'print if $F[3] =~ /\"$/' opcode.pl
790 trans transliteration (tr///) ck_match is" S
791
792 =head2 LOOP
793
bcf9d85 @rurban B-C-1.04_15
authored
794 The LOOP class signifier is B<{>.
795 It inherits from the L</LISTOP>.
6df6cc8 @rurban B-C-1.04_13
authored
796
797 struct loop {
798 BASEOP
799 OP * op_first;
800 OP * op_last;
801 OP * op_redoop;
802 OP * op_nextop;
803 OP * op_lastop;
804 };
805
806 $ perl -F"/\cI+/" -ane 'print if $F[3] =~ /\{$/' opcode.pl
807 enteriter foreach loop entry ck_null d{
808 enterloop loop entry ck_null d{
809
810 =head2 COP
811
bcf9d85 @rurban B-C-1.04_15
authored
812 The C<struct cop>, the "Control OP", changed recently a lot, as the L</BASEOP>.
813 Remember from perlguts what a COP is? Got you. A COP is nowhere described.
814
815 I would have naively called it "Context OP", but not "Control OP". So why?
816 We have a global C<PL_curcop> and then we have threads. So it cannot be global
817 anymore. A COP can be said as helper context for debugging and error information
818 to store away file and line information. But since perl is a file-based
819 compiler, not block-based, also file based pragmata and hints are stored in the
855afd1 @rurban B-C-1.04_20
authored
820 COP. So we have for every source file a seperate COP. COP's are mostly not
821 really block level contexts, just file and line information. The block level
822 contexts are not controlled via COP's, but global C<Cx> structs.
bcf9d85 @rurban B-C-1.04_15
authored
823
824 F<cop.h> says:
825
dd3580a @rurban improve docs
authored
826 Control ops (cops) are one of the two ops OP_NEXTSTATE and OP_DBSTATE
827 that (loosely speaking) are separate statements. They hold
bcf9d85 @rurban B-C-1.04_15
authored
828 information for lexical state and error reporting. At run time, C<PL_curcop> is set
829 to point to the most recently executed cop, and thus can be used to determine
830 our file-level current state.
831
832 But we need block context, eval context, subroutine context, loop context, and
833 even format context. All these are seperate structs defined in F<cop.h>.
834
835 So the COPs are not really that important, as the actual C<Cx> context structs
836 are. Just the C<CopSTASH> is, the current package symbol table hash ("stash").
837
838 Another famous COP is C<PL_compiling>, which sets the temporary compilation
839 environment.
6df6cc8 @rurban B-C-1.04_13
authored
840
841 struct cop {
842 BASEOP
843 line_t cop_line; /* line # of this command */
844 char * cop_label; /* label for this construct */
845 #ifdef USE_ITHREADS
846 char * cop_stashpv; /* package line was compiled in */
847 char * cop_file; /* file name the following line # is from */
848 #else
849 HV * cop_stash; /* package line was compiled in */
850 GV * cop_filegv; /* file the following line # is from */
851 #endif
852 U32 cop_hints; /* hints bits from pragmata */
853 U32 cop_seq; /* parse sequence number */
854 /* Beware. mg.c and warnings.pl assume the type of this is STRLEN *: */
855 STRLEN * cop_warnings; /* lexical warnings bitmask */
856 /* compile time state of %^H. See the comment in op.c for how this is
857 used to recreate a hash to return from caller. */
858 struct refcounted_he * cop_hints_hash;
859 };
860
bcf9d85 @rurban B-C-1.04_15
authored
861 The COP class signifier is B<;> and there are only two:
6df6cc8 @rurban B-C-1.04_13
authored
862
863 $ perl -F"/\cI+/" -ane 'print if $F[3] =~ /;$/' opcode.pl
864 nextstate next statement ck_null s;
865 dbstate debug next statement ck_null s;
866
855afd1 @rurban B-C-1.04_20
authored
867 C<NEXTSTATE> is replaced by C<DBSTATE> when you call perl with -d, the
868 debugger. You can even patch the C<NEXTSTATE> ops at runtime to
869 C<DBSTATE> as done in the module C<Enbugger>.
870
9b2933c @rurban name change
authored
871 For a short time there used to be three. C<SETSTATE> was
872 added 1999 (pre Perl 5.6.0) to track linenumbers correctly
873 in optimized blocks, disabled 1999 with change 4309 for Perl
874 5.6.0, and removed with 5edb5b2abb at Perl 5.10.1.
bcf9d85 @rurban B-C-1.04_15
authored
875
6df6cc8 @rurban B-C-1.04_13
authored
876 =head2 BASEOP_OR_UNOP
877
bcf9d85 @rurban B-C-1.04_15
authored
878 BASEOP_OR_UNOP has the class signifier B<%>. As the name says, it may
879 be a L</BASEOP> or L</UNOP>, it may have an optional L</op_first> field.
6df6cc8 @rurban B-C-1.04_13
authored
880
bcf9d85 @rurban B-C-1.04_15
authored
881 The list of B<%> ops is quite large, it has 84 ops.
6df6cc8 @rurban B-C-1.04_13
authored
882 Some of them are e.g.
883
884 $ perl -F"/\cI+/" -ane 'print if $F[3] =~ /%$/' opcode.pl
885 ...
886 quotemeta quotemeta ck_fun fstu% S?
887 aeach each on array ck_each % A
888 akeys keys on array ck_each t% A
889 avalues values on array ck_each t% A
890 each each ck_each % H
891 values values ck_each t% H
892 keys keys ck_each t% H
893 delete delete ck_delete % S
894 exists exists ck_exists is% S
895 pop pop ck_shift s% A?
896 shift shift ck_shift s% A?
897 caller caller ck_fun t% S?
898 reset symbol reset ck_fun is% S?
899 exit exit ck_exit ds% S?
900 ...
901
902 =head2 FILESTATOP
903
bcf9d85 @rurban B-C-1.04_15
authored
904 A FILESTATOP may be a L</UNOP>, L</PADOP>, L</BASEOP> or L</SVOP>.
6df6cc8 @rurban B-C-1.04_13
authored
905
bcf9d85 @rurban B-C-1.04_15
authored
906 It has the class signifier B<->.
6df6cc8 @rurban B-C-1.04_13
authored
907
908 The file stat OPs are created via UNI(OP_foo) in toke.c but use the
bcf9d85 @rurban B-C-1.04_15
authored
909 C<OPf_REF> flag to distinguish between OP types instead of the usual
910 C<OPf_SPECIAL> flag. As usual, if C<OPf_KIDS> is set, then we return
fbed513 @rurban release 1.04_21
authored
911 C<OPc_UNOP> so that C<walkoptree> can find our children. If C<OPf_KIDS> is not
bcf9d85 @rurban B-C-1.04_15
authored
912 set then we check C<OPf_REF>. Without C<OPf_REF> set (no argument to the
913 operator) it's an OP; with C<OPf_REF> set it's an SVOP (and the field C<op_sv> is the
6df6cc8 @rurban B-C-1.04_13
authored
914 GV for the filehandle argument).
915
916 case OA_FILESTATOP:
917 return ((o->op_flags & OPf_KIDS) ? OPc_UNOP :
918 #ifdef USE_ITHREADS
919 (o->op_flags & OPf_REF) ? OPc_PADOP : OPc_BASEOP);
920 #else
921 (o->op_flags & OPf_REF) ? OPc_SVOP : OPc_BASEOP);
922 #endif
923
924
925 lstat lstat ck_ftst u- F
926 stat stat ck_ftst u- F
927 ftrread -R ck_ftst isu- F-+
928 ftrwrite -W ck_ftst isu- F-+
929 ftrexec -X ck_ftst isu- F-+
930 fteread -r ck_ftst isu- F-+
931 ftewrite -w ck_ftst isu- F-+
932 fteexec -x ck_ftst isu- F-+
933 ftis -e ck_ftst isu- F-
934 ftsize -s ck_ftst istu- F-
935 ftmtime -M ck_ftst stu- F-
936 ftatime -A ck_ftst stu- F-
937 ftctime -C ck_ftst stu- F-
938 ftrowned -O ck_ftst isu- F-
939 fteowned -o ck_ftst isu- F-
940 ftzero -z ck_ftst isu- F-
941 ftsock -S ck_ftst isu- F-
942 ftchr -c ck_ftst isu- F-
943 ftblk -b ck_ftst isu- F-
944 ftfile -f ck_ftst isu- F-
945 ftdir -d ck_ftst isu- F-
946 ftpipe -p ck_ftst isu- F-
947 ftsuid -u ck_ftst isu- F-
948 ftsgid -g ck_ftst isu- F-
949 ftsvtx -k ck_ftst isu- F-
950 ftlink -l ck_ftst isu- F-
951 fttty -t ck_ftst is- F-
952 fttext -T ck_ftst isu- F-
953 ftbinary -B ck_ftst isu- F-
954
955 =head2 LOOPEXOP
956
bcf9d85 @rurban B-C-1.04_15
authored
957 A LOOPEXOP is almost a L<BASEOP_OR_UNOP>. It may be a L</UNOP> if stacked or
958 L</BASEOP> if special or L</PVOP> else.
6df6cc8 @rurban B-C-1.04_13
authored
959
bcf9d85 @rurban B-C-1.04_15
authored
960 C<next>, C<last>, C<redo>, C<dump> and C<goto> use C<OPf_SPECIAL> to indicate that a
961 label was omitted (in which case it's a L</BASEOP>) or else a term was
962 seen. In this last case, all except goto are definitely L</PVOP> but
963 goto is either a PVOP (with an ordinary constant label), an L</UNOP>
964 with C<OPf_STACKED> (with a non-constant non-sub) or an L</UNOP> for
965 C<OP_REFGEN> (with C<goto &sub>) in which case C<OPf_STACKED> also seems to
6df6cc8 @rurban B-C-1.04_13
authored
966 get set.
967
968 ...
969
970 =head2 OP Definition Example
971
9b2933c @rurban name change
authored
972 Let's take a simple example for a opcode definition in F<opcode.pl>:
6df6cc8 @rurban B-C-1.04_13
authored
973
974 left_shift left bitshift (<<) ck_bitop fsT2 S S
975
bcf9d85 @rurban B-C-1.04_15
authored
976 The op C<left_shift> has a check function C<ck_bitop> (normally most ops
977 have no check function, just C<ck_null>), and the options C<fsT2>.
6df6cc8 @rurban B-C-1.04_13
authored
978 The last two C<S S> describe the type of the two required operands:
979 SV or scalar. This is similar to XS protoypes.
980 The last C<2> in the options C<fsT2> denotes the class BINOP, with
981 two args on the stack.
982 Every binop takes two args and this produces one scalar, see the C<s> flag.
983 The other remaining flags are C<f> and C<T>.
984
985 C<f> tells the compiler in the first pass to call C<fold_constants()>
986 on this op. See L</"Compile pass 1: check routines and constant folding">
987 If both args are constant, the result is constant also and the op will
988 be nullified.
989
990 Now let's inspect the simple definition of this op in F<pp.c>.
9b2933c @rurban name change
authored
991 C<pp_left_shift> is the C<op_ppaddr>, the function pointer, for every
6df6cc8 @rurban B-C-1.04_13
authored
992 left_shift op.
993
994 PP(pp_left_shift)
995 {
996 dVAR; dSP; dATARGET; tryAMAGICbin(lshift,opASSIGN);
997 {
998 const IV shift = POPi;
999 if (PL_op->op_private & HINT_INTEGER) {
1000 const IV i = TOPi;
1001 SETi(i << shift);
1002 }
1003 else {
1004 const UV u = TOPu;
1005 SETu(u << shift);
1006 }
1007 RETURN;
1008 }
1009 }
1010
1011 The first IV arg is pop'ed from the stack, the second arg is left on the stack (C<TOPi>/C<TOPu>),
1012 because it is used as the return value. (I<Todo: explain the opASSIGN magic check.>)
1013 One IV or UV is produced, dependent on C<HINT_INTEGER>, set by the C<use integer> pragma.
1014 So it has a special signed/unsigned integer behaviour, which is not defined in the opcode
1015 declaration, because the API is indifferent on this, and it is also independent on the
1016 argument type. The result, if IV or UV, is entirely context dependent at compile-time
1017 ( C<use integer at BEGIN> ) or run-time ( C<$^H |= 1> ), and only stored in the op.
1018
1019 What is left is the C<T> flag, "target can be a pad". This is a useful optimization technique.
1020
1021 This is checked in the macro C<dATARGET>
1022 C<SV *targ = (PL_op->op_flags & OPf_STACKED ? sp[-1] : PAD_SV(PL_op->op_targ));>
855afd1 @rurban B-C-1.04_20
authored
1023 C<OPf_STACKED> means "Some arg is arriving on the stack." (see F<op.h>)
6df6cc8 @rurban B-C-1.04_13
authored
1024 So this reads, if the op contains C<OPf_STACKED>, the magic C<targ> ("target argument")
1025 is simply on the stack, but if not, the C<op_targ> points to a SV on a private scratchpad.
1026 "target can be a pad", voila.
1027 For reference see L<perlguts/"Putting a C value on Perl stack">.
1028
1029 =head2 Check Functions
1030
855afd1 @rurban B-C-1.04_20
authored
1031 They are defined in F<op.c> and not in F<pp.c>, because they belong tightly to the
bcf9d85 @rurban B-C-1.04_15
authored
1032 ops and newOP definition, and not to the actual pp_ opcode. That's why
855afd1 @rurban B-C-1.04_20
authored
1033 the actual F<op.c> file is bigger than F<pp.c> where the real gore for each op begins.
1034 The name of each op's check function is defined in F<opcodes.pl>, as shown above.
6df6cc8 @rurban B-C-1.04_13
authored
1035
bcf9d85 @rurban B-C-1.04_15
authored
1036 The C<ck_null> check function is the most common.
1037
1038 $ perl -F"/\cI+/" -ane 'print $F[2],"\n" if $F[2] =~ /ck_null/' opcode.pl|wc -l
1039 128
1040
1041 But we do have a lot of those check functions.
1042
1043 $ perl -F"/\cI+/" -ane 'print $F[2],"\n" if $F[2] =~ /ck_/' opcode.pl|sort -u|wc -l
1044 43
1045
1046 B<When are they called, how do they look like, what do they do.>
1047
1048 The macro CHECKOP(type,o) used to call the ck_ function has a little bit of
1049 common logic.
1050
1051 #define CHECKOP(type,o) \
1052 ((PL_op_mask && PL_op_mask[type]) \
1053 ? ( op_free((OP*)o), \
1054 Perl_croak(aTHX_ "'%s' trapped by operation mask", PL_op_desc[type]), \
1055 (OP*)0 ) \
1056 : CALL_FPTR(PL_check[type])(aTHX_ (OP*)o))
1057
1058 So when a global B<PL_op_mask> is fitting to the type the OP is nullified at once.
dd3580a @rurban improve docs
authored
1059 If not, the type specific check function with the help of F<opcodes.pl> generating
bcf9d85 @rurban B-C-1.04_15
authored
1060 the C<PL_check> array in F<opnames.h> is called.
6df6cc8 @rurban B-C-1.04_13
authored
1061
1062
1063 =head2 Constant Folding
1064
4ace4a5 @rurban improve perloptree.pod
authored
1065 In theory pretty easy. If all op's arguments in a sequence are constant and the
1066 op is sideffect free ("purely functional"), replace the op sequence with an
1067 constant op as result.
bcf9d85 @rurban B-C-1.04_15
authored
1068
1069 We do it like this: We define the C<f> flag in F<opcodes.pl>, which tells the
4ace4a5 @rurban improve perloptree.pod
authored
1070 compiler in the first pass to call C<fold_constants()> on this op. See
1071 L<"Compile pass 1: check routines and constant folding"> above. If all args are
1072 constant, the result is constant also and the op sequence will be replaced by
1073 the constant.
bcf9d85 @rurban B-C-1.04_15
authored
1074
4ace4a5 @rurban improve perloptree.pod
authored
1075 But take care, every C<f> op must be sideeffect free.
bcf9d85 @rurban B-C-1.04_15
authored
1076
1077 E.g. our C<newUNOP()> calls at the end:
1078
1079 return fold_constants((OP *) unop);
1080
dd3580a @rurban improve docs
authored
1081 OA_FOLDCONST ...
bcf9d85 @rurban B-C-1.04_15
authored
1082
1083 =head2 Lexical Pragmas
1084
1085 To implement user lexical pragmas, there needs to be a way at run time to get
1086 the compile time state of `%^H` for that block. Storing `%^H` in every
1087 block (or even COP) would be very expensive, so a different approach is
1088 taken. The (running) state of C<%^H> is serialised into a tree of HE-like
1089 structs. Stores into C<%^H> are chained onto the current leaf as a struct
1090 refcounted_he * with the key and the value. Deletes from C<%^H> are saved
1091 with a value of C<PL_sv_placeholder>. The state of C<%^H> at any point can be
1092 turned back into a regular HV by walking back up the tree from that point's
1093 leaf, ignoring any key you've already seen (placeholder or not), storing
1094 the rest into the HV structure, then removing the placeholders. Hence
1095 memory is only used to store the C<%^H> deltas from the enclosing COP, rather
1096 than the entire C<%^H> on each COP.
1097
1098 To cause actions on C<%^H> to write out the serialisation records, it has
1099 magic type 'H'. This magic (itself) does nothing, but its presence causes
1100 the values to gain magic type 'h', which has entries for set and clear.
1101 C<Perl_magic_sethint> updates C<PL_compiling.cop_hints_hash> with a store
1102 record, with deletes written by C<Perl_magic_clearhint>. C<SAVEHINTS>
1103 saves the current C<PL_compiling.cop_hints_hash> on the save stack, so that
1104 it will be correctly restored when any inner compiling scope is exited.
6df6cc8 @rurban B-C-1.04_13
authored
1105
eac02a0 @rurban perloptree.pod: add first examples, call subs and methods. See also h…
authored
1106 =head1 Examples
1107
1108 =head2 Call a subroutine
1109
1110 subname(args...) =>
1111
1112 pushmark
1113 args ...
1114 gv => subname
1115 entersub
1116
1117 =head2 Call a method
1118
1119 Here we have several combinations to define the package and the method name, either
1120 compile-time (static as constant string), or dynamic as B<GV> (subname) or
1121 B<GVSV>/B<PADSV> (package name).
1122
1123 B<method_named> holds the method name as C<sv> if know at compile time.
1124 If not B<gv> (of the name) and B<method> is used.
1125 The package name is at the top of the stack.
1126 A call stack is added with B<pushmark>.
1127
1faa1a5 @rurban * C: allow debugging without -MOd=C
authored
1128 1. Static compile time package ("class") and method:
eac02a0 @rurban perloptree.pod: add first examples, call subs and methods. See also h…
authored
1129
1130 Class->subname(args...) =>
1131
1132 pushmark
1133 const PV => "Class"
1134 args ...
1135 method_named => "subname"
1136 entersub
1137
1faa1a5 @rurban * C: allow debugging without -MOd=C
authored
1138 2. Run-time package ("object") and compile-time method:
eac02a0 @rurban perloptree.pod: add first examples, call subs and methods. See also h…
authored
1139
1140 $obj->subname(args...) =>
1141
1142 pushmark
1143 padsv/gvsv => *packagename
1144 args ...
1145 method_named => "subname"
1146 entersub
1147
1148 3. Run-time package and run-time method:
1149
1150 $obj->$meth(args...) =>
1151
1152 pushmark
1153 padsv/gvsv => *packagename
1154 args ...
1155 gvsv => GV *meth
1156 method
1157 entersub
1158
1faa1a5 @rurban * C: allow debugging without -MOd=C
authored
1159 4. Compile-time package ("class") and run-time method:
eac02a0 @rurban perloptree.pod: add first examples, call subs and methods. See also h…
authored
1160
1161 Class->$meth(args...) =>
1162
1163 pushmark
1164 const PV => "Class"
1165 args ...
1166 gvsv => GV *meth
1167 method
1168 entersub
1169
6df6cc8 @rurban B-C-1.04_13
authored
1170 =head1 Hooks
1171
1172 =head2 Special execution blocks BEGIN, CHECK, UNITCHECK, INIT, END
1173
1174 Perl keeps special arrays of subroutines that are executed at the
1175 beginning and at the end of a running Perl program and its program
1176 units. These subroutines correspond to the special code blocks:
1177 C<BEGIN>, C<CHECK>, C<UNITCHECK>, C<INIT> and C<END>. (See basics at
1178 L<perlmod/basics>.)
1179
1180 Such arrays belong to Perl's internals that you're not supposed to
1181 see. Entries in these arrays get consumed by the interpreter as it
1182 enters distinct compilation phases, triggered by statements like
1183 C<require>, C<use>, C<do>, C<eval>, etc. To play as safest as
1184 possible, the only allowed operations are to add entries to the start
1185 and to the end of these arrays.
1186
1187 BEGIN, UNITCHECK and INIT are FIFO (first-in, first-out) blocks while
1188 CHECK and END are LIFO (last-in, first-out).
1189
1190 L<Devel::Hook> allows adding code the start or end of these
1191 blocks. L<Manip::END> even tries to remove certain entries.
1192
1193 =head3 The BEGIN block
1194
1195 A special array of code at C<PL_beginav>, that is executed before
1196 C<main_start>, the first op, which is defined be called C<ENTER>.
1197 E.g. C<use module;> adds its require and importer code into the BEGIN
1198 block.
1199
1200 =head3 The CHECK block
1201
1202 The B compiler starting block at C<PL_checkav>. This hooks int the
1203 check function which is executed for every op created in bottom-up,
1204 basic order.
1205
1206 =head3 The UNITCHECK block
1207
1208 A new block since Perl 5.10 at C<PL_unitcheckav> runs right after the
1209 CHECK block, to seperate possible B compilation hooks from other
1210 checks.
1211
1212 =head3 The INIT block
1213
1214 At C<PL_initav>.
1215
1216 =head3 The END block
1217
1218 At C<PL_endav>.
1219
1220 L<Manip::END> started to mess around with this block.
1221
1222 The array contains an C<undef> for each block that has been
1223 encountered. It's not really an C<undef> though, it's a kind of raw
fbed513 @rurban release 1.04_21
authored
1224 coderef that's not wrapped in a scalar ref. This leads to funky error
6df6cc8 @rurban B-C-1.04_13
authored
1225 messages like C<Bizarre copy of CODE in sassign> when you try to assign
1226 one of these values to another variable. See L<Manip::END> how to
1227 manipulate these values array.
1228
1229 =head2 B and O module. The perl compiler.
1230
fbed513 @rurban release 1.04_21
authored
1231 Malcom Beattie's B modules hooked into the early op tree stages to
6df6cc8 @rurban B-C-1.04_13
authored
1232 represent the internal ops as perl objects and added the perl compiler
fbed513 @rurban release 1.04_21
authored
1233 backends. See L<B> and L<perlcompile.pod>.
6df6cc8 @rurban B-C-1.04_13
authored
1234
dd3580a @rurban improve docs
authored
1235 The three main compiler backends are still B<Bytecode>, B<C> and B<CC>.
6df6cc8 @rurban B-C-1.04_13
authored
1236
1237 I<Todo: Describe B's object representation a little bit deeper, its
1238 CHECK hook, its internal transformers for Bytecode (asm and vars) and
1239 C (the sections).>
1240
1241 =head2 MAD
1242
bcf9d85 @rurban B-C-1.04_15
authored
1243 MAD stands for "Misc Attributed Data".
6df6cc8 @rurban B-C-1.04_13
authored
1244
dd3580a @rurban improve docs
authored
1245 Larry Wall worked on a new MAD compiler backend outside of the B
1246 approach, dumping the internal op tree representation as B<XML> or
1247 B<YAML>, not as tree of perl B objects.
bcf9d85 @rurban B-C-1.04_15
authored
1248
1249 The idea is that all the information needed to recreate the original source is
fbed513 @rurban release 1.04_21
authored
1250 stored in the op tree. To do this the tokens for the ops are associated with ops,
bcf9d85 @rurban B-C-1.04_15
authored
1251 these madprops are a list of key-value pairs, where the key is a character as
855afd1 @rurban B-C-1.04_20
authored
1252 listed at the end of F<op.h>, the value normally is a string, but it might also be
bcf9d85 @rurban B-C-1.04_15
authored
1253 a op, as in the case of a optimized op ('O'). Special for the whitespace key '_'
1254 (whitespace before) and '#' (whitespace after), which indicate the whitespace or
1255 comment before/after the previous key-value pair.
855afd1 @rurban B-C-1.04_20
authored
1256
bcf9d85 @rurban B-C-1.04_15
authored
1257 Also when things normally compiled out, like a BEGIN block, which normally do
1258 not results in any ops, instead create a NULLOP with madprops used to recreate
1259 the object.
6df6cc8 @rurban B-C-1.04_13
authored
1260
bcf9d85 @rurban B-C-1.04_15
authored
1261 I<Is there any documentation on this?>
6df6cc8 @rurban B-C-1.04_13
authored
1262
bcf9d85 @rurban B-C-1.04_15
authored
1263 Why this awful XML and not the rich tree of perl objects?
855afd1 @rurban B-C-1.04_20
authored
1264
bcf9d85 @rurban B-C-1.04_15
authored
1265 Well there's an advantage.
6df6cc8 @rurban B-C-1.04_13
authored
1266 The MAD XML can be seen as some kind of XML Storable/Freeze of the B
fbed513 @rurban release 1.04_21
authored
1267 op tree, and can be therefore converted outside of the CHECK block,
dd3580a @rurban improve docs
authored
1268 which means you can easier debug the conversion (= compilation)
1269 process. To debug the CHECK block in the B backends you have to
1270 use the L<B::Debugger> B<Od> or B<Od_o> modules, which defer the
1271 CHECK to INIT.
6df6cc8 @rurban B-C-1.04_13
authored
1272
dd3580a @rurban improve docs
authored
1273 B<kurila> L<http://search.cpan.org/dist/kurila/> uses MAD to convert
6df6cc8 @rurban B-C-1.04_13
authored
1274 Perl 5 source to the kurila dialect.
1275
bcf9d85 @rurban B-C-1.04_15
authored
1276 To convert a file 'source.pm' from Perl 5.10 to Kurila you need to do:
1277
1278 kurilapath=/usr/src/perl/kurila-1.9
1279 bleadpath=/usr/src/perl/blead
1280 cd $kurilapath
1281 madfrom='perl-5.10' madto='kurila-1.9' \
1282 madconvert="/usr/bin/perl $kurilapath/mad/p5kurila.pl" \
1283 madpath="$bleadpath/mad" \
1284 mad/convert /path/to/source.pm
1285
1286 B<PPI> L<http://search.cpan.org/dist/PPI/>, a Perl 5 source level parser not
fbed513 @rurban release 1.04_21
authored
1287 related to the op tree at all, could also have been used for that.
6df6cc8 @rurban B-C-1.04_13
authored
1288
1289 =head2 Pluggable runops
1290
855afd1 @rurban B-C-1.04_20
authored
1291 The compile tree is executed by one of two existing runops functions, in F<run.c>
fbed513 @rurban release 1.04_21
authored
1292 or in F<dump.c>. C<Perl_runops_debug> is used with C<DEBUGGING> and the faster
bcf9d85 @rurban B-C-1.04_15
authored
1293 C<Perl_runops_standard> is used otherwise (See below in L</"Walkers">). For fine
1294 control over the execution of the compile tree it is possible to provide your
1295 own runops function.
6df6cc8 @rurban B-C-1.04_13
authored
1296
1297 It's probably best to copy one of the existing runops functions and
1298 change it to suit your needs. Then, in the C<BOOT> section of your XS
1299 file, add the line:
1300
1301 PL_runops = my_runops;
1302
1303 This function should be as efficient as possible to keep your programs
dd3580a @rurban improve docs
authored
1304 running as fast as possible. See L<Jit> for an even faster just-in-time
1305 compilation runloop.
6df6cc8 @rurban B-C-1.04_13
authored
1306
bcf9d85 @rurban B-C-1.04_15
authored
1307 =head3 Walkers or runops
6df6cc8 @rurban B-C-1.04_13
authored
1308
dd3580a @rurban improve docs
authored
1309 The standard op tree B<walker> or B<runops> is as simple as this fast
bcf9d85 @rurban B-C-1.04_15
authored
1310 C<Perl_runops_standard()> in (F<run.c>). It starts with C<main_start> and walks
1311 the C<op_next> chain until the end. No need to check other fields, strictly
1312 linear through the tree.
6df6cc8 @rurban B-C-1.04_13
authored
1313
1314 int
1315 Perl_runops_standard(pTHX)
1316 {
1317 dVAR;
1318 while ((PL_op = CALL_FPTR(PL_op->op_ppaddr)(aTHX))) {
dd3580a @rurban improve docs
authored
1319 PERL_ASYNC_CHECK(); /* until 5.13.2 */
6df6cc8 @rurban B-C-1.04_13
authored
1320 }
1321 TAINT_NOT;
1322 return 0;
1323 }
1324
fbed513 @rurban release 1.04_21
authored
1325 To inspect the op tree within a perl program, you can also hook C<PL_runops> (see
bcf9d85 @rurban B-C-1.04_15
authored
1326 above at L</"Pluggable runops">) to your own perl walker (see e.g. L<B::Utils>
1327 for various useful walkers), but you cannot modify the tree from within the B
855afd1 @rurban B-C-1.04_20
authored
1328 accessors, only via XS. Or via L<B::Generate> as explained in Simon Cozen's
1329 "Hacking the Optree for Fun..." L<http://www.perl.com/pub/a/2002/05/07/optree.html>.
6df6cc8 @rurban B-C-1.04_13
authored
1330
bcf9d85 @rurban B-C-1.04_15
authored
1331 I<Todo: Show the other runloops, and esp. the B:Utils ones.>
6df6cc8 @rurban B-C-1.04_13
authored
1332 I<Todo: Describe the dumper, the debugging and more extended walkers.>
1333
eac02a0 @rurban perloptree.pod: add first examples, call subs and methods. See also h…
authored
1334 =head1 SEE ALSO
1335
1336 =head2 Internal and external modifications
6df6cc8 @rurban B-C-1.04_13
authored
1337
1338 See the short description of the internal optimizer in the "Brief Summary".
1339
1340 I<Todo: Describe the exported variables and functions which can be
1341 hooked, besides simply adding code to the blocks.>
1342
1343 Via L</"Pluggable runops"> you can provide your own walker function, as it
1344 is done in most B modules. Best see L<B::Utils>.
1345
1346 You may also create custom ops at runtime (well, strictly speaking at
1347 compile-time) via L<B::Generate>.
1348
eac02a0 @rurban perloptree.pod: add first examples, call subs and methods. See also h…
authored
1349 =head2 Modules
6df6cc8 @rurban B-C-1.04_13
authored
1350
fbed513 @rurban release 1.04_21
authored
1351 The most important op tree module is L<B::Concise> by Stephen McCamant.
6df6cc8 @rurban B-C-1.04_13
authored
1352
fbed513 @rurban release 1.04_21
authored
1353 L<B::Utils> provides abstract-enough op tree grep's and walkers with
6df6cc8 @rurban B-C-1.04_13
authored
1354 callbacks from the perl level.
1355
1356 L<Devel::Hook> allows adding perl hooks into the BEGIN, CHECK,
1357 UNITCHECK, INIT blocks.
1358
1359 L<Devel::TypeCheck> tries to verify possible static typing for
1360 expressions and variables, a pretty hard problem for compilers,
855afd1 @rurban B-C-1.04_20
authored
1361 esp. with such dynamic and untyped variables as Perl 5.
6df6cc8 @rurban B-C-1.04_13
authored
1362
dd3580a @rurban improve docs
authored
1363 Reini Urban maintains the interactive op tree debugger L<B::Debugger>,
1364 the Compiler suite (B::C, B::CC, B::Bytecode), L<B::Generate> and
1365 is working on L<Jit>.
6df6cc8 @rurban B-C-1.04_13
authored
1366
eac02a0 @rurban perloptree.pod: add first examples, call subs and methods. See also h…
authored
1367 =head2 Various Articles
6df6cc8 @rurban B-C-1.04_13
authored
1368
1369 The best source of information is the source. It is very well documented.
1370
1371 Simon Cozens has posted the course material to NetThink's
1372 L<http://books.simon-cozens.org/index.php/Perl_5_Internals#The_Lexer_and_the_Parser>
1373 training course. This is the currently best available description on
1374 that subject.
1375
1376 "Hacking the Optree for Fun..." at
1377 L<http://www.perl.com/pub/a/2002/05/07/optree.html> is the next step by
1378 Simon Cozens.
1379
4ace4a5 @rurban improve perloptree.pod
authored
1380 Scott Walters added more details at L<http://perldesignpatterns.com/?PerlAssembly>
1381
6df6cc8 @rurban B-C-1.04_13
authored
1382 Joshua ben Jore wrote a 50 minute presentation on "Perl 5
1383 VM guts" at L<http://diotalevi.isa-geek.net/~josh/Presentations/Perl%205%20VM/>
fbed513 @rurban release 1.04_21
authored
1384 focusing on the op tree for SPUG, the Seattle Perl User's Group.
6df6cc8 @rurban B-C-1.04_13
authored
1385
1386 Eric Wilhelm wrote a brief tour through the perl compiler backends for
1387 the impatient refactorerer. The perl_guts_tour as mp3
1388 L<http://scratchcomputing.com/developers/perl_guts_tour.html> or as
1389 pdf L<http://scratchcomputing.com/developers/perl_guts_tour.pdf>
1390
1391 This text was created in this wiki article:
1392 L<http://www.perlfoundation.org/perl5/index.cgi?optree_guts>
4ace4a5 @rurban improve perloptree.pod
authored
1393 The svn version should be more actual.
bcf9d85 @rurban B-C-1.04_15
authored
1394
1395 =head1 Conclusion
1396
4ace4a5 @rurban improve perloptree.pod
authored
1397 So this is about 30% of the basic op tree information so far. Not speaking about
1398 the guts. Simon Cozens and Scott Walters have more 30%, in the source are more
1399 10% to copy&paste, and in the compilers and run-time information is the rest. I
1400 hope with the help of some hackers we'll get it done, so that some people will
1401 begin poking around in the B backends. And write the wonderful new dump/undump
1402 functionality (which actually worked in the early years on Solaris) to
1403 save-image and load-image at runtime as in LISP, analyse and optimize the
1404 output, output PIR (parrot code), emit LLVM or another JIT optimized code or
1405 even write assemblers. I have a simple one at home. :)
bcf9d85 @rurban B-C-1.04_15
authored
1406
855afd1 @rurban B-C-1.04_20
authored
1407 Written 2008 on the perl5 wiki with socialtext and pod in parallel
1408 by Reini Urban, CPAN ID rurban.
Something went wrong with that request. Please try again.