summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorDave Mitchell <davem@fdisolutions.com>2004-11-12 18:59:06 +0000
committerDave Mitchell <davem@fdisolutions.com>2004-11-12 18:59:06 +0000
commit61b743bbcef6a7a9fafaccaf3e76f5b76165e33b (patch)
treeabcdea651a21257f3318fc8a3f9dd1b6e5986c99
parent9277038781ef547cb9d994aebe1ec82e3270d9ac (diff)
downloadperl-61b743bbcef6a7a9fafaccaf3e76f5b76165e33b.tar.gz
Add some descriptive text from Larry to op.c on how optrees are built
p4raw-id: //depot/perl@23494
-rw-r--r--op.c39
1 files changed, 37 insertions, 2 deletions
diff --git a/op.c b/op.c
index 9b33ff2f2c..614e211135 100644
--- a/op.c
+++ b/op.c
@@ -41,6 +41,38 @@
* is made, called opmini.c.
*/
+/*
+Perl's compiler is essentially a 3-pass compiler with interleaved phases:
+
+ A bottom-up pass
+ A top-down pass
+ An execution-order pass
+
+The bottom-up pass is represented by all the "newOP" routines and
+the ck_ routines. The bottom-upness is actually driven by yacc.
+So at the point that a ck_ routine fires, we have no idea what the
+context is, either upward in the syntax tree, or either forward or
+backward in the execution order. (The bottom-up parser builds that
+part of the execution order it knows about, but if you follow the "next"
+links around, you'll find it's actually a closed loop through the
+top level node.
+
+Whenever the bottom-up parser gets to a node that supplies context to
+its components, it invokes that portion of the top-down pass that applies
+to that part of the subtree (and marks the top node as processed, so
+if a node further up supplies context, it doesn't have to take the
+plunge again). As a particular subcase of this, as the new node is
+built, it takes all the closed execution loops of its subcomponents
+and links them into a new closed loop for the higher level node. But
+it's still not the real execution order.
+
+The actual execution order is not known till we get a grammar reduction
+to a top-level unit like a subroutine or file that will be called by
+"name" rather than via a "next" pointer. At that point, we can call
+into peep() to do that code's portion of the 3rd pass. It has to be
+recursive, but it's recursive on basic blocks, not on tree nodes.
+*/
+
#include "EXTERN.h"
#define PERL_IN_OP_C
#include "perl.h"
@@ -4818,7 +4850,8 @@ Perl_newSVREF(pTHX_ OP *o)
return newUNOP(OP_RV2SV, 0, scalar(o));
}
-/* Check routines. */
+/* Check routines. See the comments at the top of this file for details
+ * on when these are called */
OP *
Perl_ck_anoncode(pTHX_ OP *o)
@@ -6403,7 +6436,9 @@ Perl_ck_substr(pTHX_ OP *o)
return o;
}
-/* A peephole optimizer. We visit the ops in the order they're to execute. */
+/* A peephole optimizer. We visit the ops in the order they're to execute.
+ * See the comments at the top of this file for more details about when
+ * peep() is called */
void
Perl_peep(pTHX_ register OP *o)