Start Lecture #9
When we eliminate the left recursion, we get the lower table on the right. It is a good illustration of dependencies. Follow it through and see that you get the same syntax tree as for the left-recursive version.
This course emphasizes top-down parsing (at least for the labs) and hence we must eliminate left recursion. The resulting grammars often need inherited attributes, since operations and operands are in different productions. But sometimes the language itself demands inherited attributes. Consider two ways to declare a 3x4, two-dimensional array.
array  of array  of int and int
Assume that we want to produce a tree structure like the one the right for either of the array declarations on the left. The tree structure is generated by calling a function array(num,type). Our job is to create an SDD so that the function gets called with the correct arguments.
|A → ARRAY [ NUM ] OF A1||A.t=array(NUM.val,A1.t)|
|A → INT||A.t=integer|
|A → REAL||A.t=real|
For the first language representation of arrays (found in Ada and
in lab 3), it is easy to generate an S-attributed
(non-left-recursive) grammar based on
A → ARRAY [ NUM ] OF A | INT | REAL
This is shown in the upper table on the left.
On the board draw the parse tree and see that simple synthesized attributes above suffice.
|T → B C||T.t=C.t|
|B → INT||B.t=integer|
|B → REAL||B.t=real|
|C → [ NUM ] C1||C.t=array(NUM.val,C1.t)|
|C → ε||C.t=C.b|
For the second language representation of arrays (the C-style), we need some smarts (and some inherited attributes) to move the int all the way to the right. Fortunately, the result, shown in the table on the right, is L-attributed and therefore all is well.
Note that, instead of a third column stating whether the attribute is synthesized or inherited, I have adopted the convention of shading the inherited attribute definitions with a pink background.
Also note that this is not necessary.
That is, one can look at a production and the associated attribute
definition and determine if the attribute is inherited or
How is this done?
Answer: If the attribute being defined (i.e., the one on the LHS of the definition) is associated with the nonterminal on the LHS of the production, the attribute is synthesized. If the attribute being defined is associated with a nonterminal on the RHS of the production, the attribute is inherited.
The idea is that instead of the SDD approach, which requires that we build a parse tree and then perform the semantic rules in an order determined by the dependency graph, we can attach semantic actions to the grammar (as in chapter 2) and perform these actions during parsing, thus saving the construction of the parse tree.
But except for very simple languages, the tree cannot be eliminated. Modern commercial quality compilers all make multiple passes over the tree, which is actually the syntax tree (technically, the abstract syntax tree) rather than the parse tree (the concrete syntax tree).
If parsing is done bottom up and the SDD is S-attributed, one can generate an SDT with the actions at the end (hence, postfix). In this case the action is perform at the same time as the RHS is reduced to the LHS.
A good summary of the available techniques.
Recall that in recursive-descent parsing there is one procedure for each nonterminal. Assume the SDD is L-attributed.
Also assume the grammar is LL(1) so that we can employ predictive parsing and not have to worry about backtracking. In this case we have a procedure for each production.
Then the procedure P for a given production is implemented as follows.
Basically skipped. It is interesting that this bottom-up technique requires an LL (not just LR) language.
Assume we have a parse tree as produced, for example, by your lab3. You now want to write the semantics analyzer, or intermediate code generator, or lab 4. In any of these cases you have semantic rules or actions (for lab4 it will be semantic rules) that need to be performed. Assume the SDD or SDT is L-attributed (that is my job for lab4), so we don't have to worry about dependence loops.
You start to write
which will be initially called with tree-node=root. The procedure will perform an Euler-tour traversal of the parse tree and during its visits of the nodes, it will evaluate the relevant semantic rules.
The visit() procedure is basically a big switch statement where the cases correspond to the different productions in the grammar. The tree-node is the LHS of the production and the children are the RHS.
By first switching on the tree-node and then inspecting enough of the children, visit() can tell which production the tree-node corresponds to and which semantic rules to apply.
As described in 5.5.1 above, visit() has received as parameters (in addition to tree-node), the inherited attributes of the node. The traversal calls itself recursively, with the tree-node argument set to the leftmost child, then calls again using the next child, etc. Each time, the child is passed the inherited attributes.
When each child returns, it passes back its synthesized attributes.
After the last child returns, the parent returns, passing back the synthesized attributes that were calculated.
A programming point is that, since tree-node can be any node, visit() must be prepared to accept as parameters any inherited attribute that any nonterminal can have.
Instead of a giant switch, you could have separate routines for each nonterminal and just switch on the productions having this nonterminal as LHS.
In this case each routine need be prepared to accept as parameters only all the inherited attributes that its nonterminal can have.
You could have separate routines for each production and thus each routine has as parameters exactly the inherited attributes that this production receives.
To do this requires knowing which visit() procedure to call for
each nonterminal (child node of the tree).
For example, assume you are processing the production
B → C D
You need to know which production to call for C (remember that C can be the LHS of many different productions).
Homework: Read Chapter 6.
The difference between a syntax DAG and a syntax tree is that the
former can have undirected cycles.
DAGs are useful where there are multiple, identical portions in a
The common case of this is for expressions where there often are
For example in the expression
X + a + b + c - X + ( a + b + c )
each individual variable is a common subexpression. But a+b+c is not since the first occurrence has the X already added. This is a real difference when one considers the possibility of overflow or of loss of precision. The easy case is
x + y * z * w - ( q + y * z * w )
where y*z*w is a common subexpression.
It is easy to find such common subexpressions. The constructor Node() above checks if an identical node exists before creating a new one. So Node ('/',left,right) first checks if there is a node with op='/' and children left and right. If so, a reference to that node is returned; if not, a new node is created as before.
Often one stores the tree or DAG in an array, one entry per node.
Then the array index, rather than a pointer, is used to reference a
This index is called the node's value-number and the triple
<op, value-number of left, value-number of right>
is called the signature of the node. When Node(op,left,right) needs to determine if an identical node exists, it simply searches the table for an entry with the required signature.
Searching an unordered array is slow; there are many better data structures to use. Hash tables are a good choice.
Instructions of the form op a,b,c, where op is
lshift a,b,4 // left shift b by 4 and place result in a add a,b,c // a = b + c a = b + c // alternate (more natural) representation of above
If we are starting with an expression DAG (or syntax tree if less aggressive), then transforming into 3-address code is just a topological sort and an assignment of a 3-address operation with a new name for the result to each interior node (the leaves already have names and values).
A key point is that nodes in an expression dag (or tree) have at most 2 children so three-address code is easy. As we produce three-address code for various constructs, we may have to generate several instructions to translate one construct.
For example, (B+A)*(Y-(B+A)) produces the DAG on the right, which yields the following 3-address code.
t1 = B + A t2 = Y - t1 t3 = t1 * t2
We use the term 3-address since instructions in our
intermediate-code consist of one
elementary operation with
three operands, each of which is often an address.
Typically two of the addresses represent source operands or
arguments of the operation and the third represents the result.
Some of the 3-address operations have fewer than three addresses; we
simply think of the missing addresses as unused (or ignored) fields
in the instruction.
Consider Q = Z; or A[f(x)+B*D] = g(B+C*h(x,y));. I am using  for array reference and () for function call).
From a macroscopic view, we have three tasks.
Note the differences between L-values, quantities that can appear on the LHS of an assignment, and and R-values, quantities that can appear only on the RHS.
There is no universally agreed to set of three-address instructions or to whether 3-address code should be the intermediate code for the compiler. Some prefer a set close to a machine architecture. Others prefer a higher-level set closer to the source, for example, subsets of C have been used. Others prefer to have multiple levels of intermediate code in the compiler and define a compilation phase that converts the high-level intermediate code into the low-level intermediate code. What follows is the set proposed in the book.
In the list below, x, y, and z are addresses; i is an integer,
not an address); and L is a symbolic label.
The instructions can be thought of as numbered and the labels can be
converted to the numbers with another pass over the output or
backpatching, which is discussed below.
param S param U param V t = call G,2 param t param W A = call F,3This is not important for lab4 since we do not have functions, and procedures cannot be embedded one inside the other the way functions can.
Indexed Copy ops. x = y[i] x[i] = y.
x[i] is the address that is the-value-of-i locations after x; in particular x is the same address as x. Similarly for y[i]. But a difference that, since y[i] is on the RHS, the address is dereferenced and the value in the address is what is used.
Note that x[i] = y[j] is not permitted as that requires 4 addresses. x[i] = y[i] could be permitted, but is not.
Quads are an easy, almost obvious, way to represent the three address instructions: put the op into the first of four fields and the three addresses into the remaining three fields. Some instructions do not use all the fields. Many operands will be references to entries in tables (e.g., the identifier table).