1 Dependency Graphs
2 Ordering the Evaluation of Attributes
3 S-Attributed Definitions
4 L-Attributed Definitions
5 Semantic Rules with Controlled Side Effects
6 Exercises for Section 5.2

**Evaluation Orders for SDD's**

*1 Dependency Graphs*

*2 Ordering the Evaluation of
Attributes*

*3 S-Attributed Definitions*

*4 L-Attributed Definitions*

*5 Semantic Rules with Controlled
Side Effects*

*6 Exercises for Section 5.2*

"Dependency graphs" are a useful tool for determining an
evaluation order for the attribute instances in a given parse tree. While an
annotated parse tree shows the values of attributes, a dependency graph helps
us determine how those values can be computed.

In this section, in addition to dependency graphs, we define two
impor-tant classes of SDD's: the "S-attributed" and the more general
"L-attributed" SDD's. The translations specified by these two classes
fit well with the parsing methods we have studied, and most translations
encountered in practice can be written to conform to the requirements of at
least one of these classes.

**1. Dependency Graphs**

A *dependency graph* depicts the
flow of information among the attribute in-stances in a particular parse tree;
an edge from one attribute instance to an-other means that the value of the
first is needed to compute the second. Edges express constraints implied by the
semantic rules. In more detail:

For each parse-tree node, say a
node labeled by grammar symbol *X,* the
dependency graph has a node for each attribute associated with *X.*

Suppose that a semantic rule
associated with a production *p*
defines the value of synthesized attribute *A.b*
in terms of the value of *X.c* (the
rule

may define *A.b* in terms of
other attributes in addition to *X.c).*
Then, the dependency graph has an edge from *X.c*
to *A.b.* More precisely, at every node
*N* labeled *A* where production *p* is
applied, create an edge to attribute *b*
at *N,* from the attribute c at the
child of *N* corresponding to this
instance of the symbol *X* in the body
of the production.^{2}

*
*Suppose that a semantic rule
associated with a production *p*
defines the value of inherited attribute *B.c*
in terms of the value of *X.a.* Then,
the dependency graph has an edge from *X.a*
to *B.c.* For each node *N* labeled *B *that corresponds to an occurrence of this* B *in the body of production*
p, *create an edge to attribute c at* N
*from the attribute* a *at the node* M *that corresponds to this occurrence
of *X.* Note that *M* could be either the parent or a sibling of *N.*

*
*

Since a
node ** N**
can have several children labeled

Example
5.4: Consider the following production and rule:

At every node *N* labeled *E,* with children corresponding to the
body of this production, the synthesized attribute *val* at *N* is computed
using the values of *val *at the two
children, labeled* E *and* T. *Thus, a portion of the dependency* *graph for every parse tree in which
this production is used looks like Fig. 5.6. As a convention, we shall show the
parse tree edges as dotted lines, while the edges of the dependency graph are
solid.

Example
5.5 : An example of a complete dependency graph appears in Fig. 5.7. The nodes
of the dependency graph, represented by the numbers 1 through 9, correspond to
the attributes in the annotated parse tree in Fig. 5.5.

Nodes 1 and 2 represent the attribute *lexval* associated with the two leaves labeled digit . Nodes 3 and 4
represent the attribute *val*
associated with the two nodes labeled *F.*
The edges to node 3 from 1 and to node 4 from 2 result from the semantic rule
that defines F.val in terms of
digit.lexval In fact, F.val equals digit
.lexval, but the edge represents dependence, not equality.

Nodes 5 and 6 represent the inherited attribute T'.inh associated with
each of the occurrences of nonterminal T'. The edge to 5 from 3 is due to the
rule T'.inh = F.val, which defines
T'.inh at the
right child of the root from
F.val at the left child. We see
edges to 6 from node 5 for T'.inh and from node 4 for F.val, because these
values are multiplied to evaluate the attribute inh at node 6.

Nodes 7 and 8 represent the synthesized attribute syn associated with
the occurrences of X". The edge to node 7 from 6 is due to the semantic
rule T'.syn = T'.inh associated with production 3 in Fig. 5.4. The edge to node
8 from 7 is due to a semantic rule associated with production 2.

Finally, node 9 represents the attribute T.val. The edge to 9 from 8 is due
to the semantic rule, T.val = T'.syn, associated with production 1.

**2. Ordering the Evaluation of
Attributes**

The dependency graph characterizes the possible orders in which we can
evalu-ate the attributes at the various nodes of a parse tree. If the dependency
graph has an edge from node M to node N, then the attribute corresponding to M
must be evaluated before the attribute of N. Thus, the only allowable orders of
evaluation are those sequences of nodes N1, N2,... ,Nk such that if there is an
edge of the dependency graph from Ni to Nj, then i < j. Such an ordering
embeds a directed graph into a linear order, and is called a topological sort
of the graph.

If there is any cycle in the graph, then there are no topological sorts;
that is, there is no way to evaluate the SDD on this parse tree. If there are
no cycles, however, then there is always at least one topological sort. To see
why, since there are no cycles, we can surely find a node with no edge
entering. For if there were no such node, we could proceed from predecessor to
predecessor until we came back to some node we had already seen, yielding a
cycle. Make this node the first in the topological order, remove it from the
dependency graph, and repeat the process on the remaining nodes.

E x a m p l e **5 . 6** : The
dependency graph of Fig. 5.7 has no cycles. One topologi-cal sort is the order
in which the nodes have already been numbered: 1,2, ... ,9 . Notice that every
edge of the graph goes from a node to a higher-numbered node, so this order is
surely a topological sort. There are other topological sorts as well, such as
1,3,5,2,4,6,7,8,9 . •

**3.** **S-Attributed Definitions**

As mentioned earlier, given an SDD, it is very hard to tell whether
there exist any parse trees whose dependency graphs have cycles. In practice,
translations can be implemented using classes of SDD's that guarantee an
evaluation order, since they do not permit dependency graphs with cycles.
Moreover, the two classes introduced in this section can be implemented
efficiently in connection with top-down or bottom-up parsing.

The first class is defined as follows:

• An SDD is *S-attributed* if every attribute is synthesized.

E x a m p l e **5 . 7** : The SDD
of Fig. 5.1 is an example of an S-attributed definition. Each attribute, *L.val, E.val, T.val,* and *F.val* is synthesized. •

When an SDD is S-attributed, we can evaluate its attributes in any
bottom-up order of the nodes of the parse tree. It is often especially simple
to evaluate the attributes by performing a postorder traversal of the parse
tree and evalu-ating the attributes at a node *N* when the traversal leaves *N*
for the last time. That is, we apply the function *postorder,* defined below, to the root of the parse tree (see also
the box "Preorder and Postorder Traversals" in Section 2.3.4):

*postorder(N)* *{*

for ( each child *C* of *N,* from the left ) *postorder(C);*

evaluate the attributes associated with node *N;*

}

S-attributed definitions can be implemented during bottom-up parsing,
since a bottom-up parse corresponds to a postorder traversal. Specifically,
postorder corresponds exactly to the order in which an LR parser reduces a
production body to its head. This fact will be used in Section 5.4.2 to
evaluate synthesized attributes and store them on the stack during LR parsing,
without creating the tree nodes explicitly.

**4. L-Attributed Definitions**

The second class of SDD's is called *L-attributed
definitions.* The idea behind this class is that, between the attributes
associated with a production body, dependency-graph edges can go from left to
right, but not from right to left (hence "L-attributed"). More
precisely, each attribute must be either

1. Synthesized, or

2. Inherited, but with the rules limited as follows. Suppose that there
is a production A -> X1 X2 ....... Xn, and that there is an inherited
attribute Xi.a computed by a rule associated with this production. Then the
rule may use only:

Inherited attributes associated
with the head A.

Either inherited or synthesized
attributes associated with the occurrences of symbols X1, X2,... , X(i-1) located to
the left of Xi.

Inherited or synthesized
attributes associated with this occurrence of Xi itself, but only in such a way
that there are no cycles in a dependency graph formed by the attributes of this
X i .

Example 5.8 : The SDD in Fig. 5.4 is L-attributed. To see why, consider
the semantic rules for inherited attributes, which are repeated here for
convenience:

The first of these rules defines the inherited attribute T'.inh using
only F.val, and F appears to the left of T' in the production body, as
required. The second rule defines T[.inh using the inherited attribute T'.inh
associated with the head, and F.val, where F appears to the left of T[ in the
production body.

In each of these cases, the rules use information "from above or
from the left," as required by the class. The remaining attributes are
synthesized. Hence, the SDD is L-attributed. •

Example 5.9 : Any SDD containing the following production and rules
cannot be L-attributed:

The first rule, A.s = B.b, is a legitimate rule in either an
S-attributed or L-attributed SDD. It defines a synthesized attribute A.s in
terms of an attribute at a child (that is, a symbol within the production
body).

The second rule defines an inherited attribute B.i, so the entire SDD
cannot be S-attributed. Further, although the rule is legal, the SDD cannot be
L- attributed, because the attribute C.c is used to help define B.i,
and C is to the right of B in the production body. While attributes at siblings in a parse tree
may be used in L-attributed SDD's, they must be to the left of the symbol whose
attribute is being defined.

**5. Semantic Rules with Controlled
Side Effects**

In practice, translations involve side effects: a desk calculator might
print a result; a code generator might enter the type of an identifier into a
symbol table. With SDD's, we strike a balance between attribute grammars and
translation schemes. Attribute grammars have no side effects and allow any
evaluation order consistent with the dependency graph. Translation schemes
impose left-to-right evaluation and allow semantic actions to contain any
program fragment; translation schemes are discussed in Section 5.4.

We shall control side effects in SDD's in one of the following ways:

Permit incidental side effects that do not constrain attribute
evaluation. In other words, permit side effects when attribute evaluation based
on any topological sort of the dependency graph produces a "correct"
translation, where "correct" depends on the application.

Constrain the allowable evaluation orders, so that the same translation
is produced for any allowable order. The constraints can be thought of as
implicit edges added to the dependency graph.

As an example of an incidental side effect, let us modify the desk
calculator of Example 5 . 1 to print a result. Instead of the rule L.val =
E.val, which saves the result in the synthesized attribute L.val, consider:

Semantic

Semantic rules that are executed for their side effects, such as
print(E.val), will be treated as the definitions of dummy synthesized
attributes associated with the head of the production. The modified SDD
produces the same translation under any topological sort, since the print statement
is executed at the end, after the result is computed into E.val.

Example 5.10 : The SDD in Fig. 5 . 8 takes a simple declaration D
consisting of a basic type T followed by a list L of identifiers. T can be int
or float. For each identifier on the list, the type is entered into the
symbol-table entry for the identifier. We assume that entering the type for one
identifier does not affect the symbol-table entry for any other identifier.
Thus, entries can be updated in any order. This SDD does not check whether an
identifier is declared more than once; it can be modified to do so.

Nonterminal *D* represents a
declaration, which, from production 1, consists of a type *T* followed by a list *L* of
identifiers. *T* has one attribute, *T.type,* which is the type in the
declaration *D.* Nonterminal *L* also has one attribute, which we call *ink* to emphasize that it is an inherited
attribute. The purpose of *L.inh *is to
pass the declared type down the list of identifiers, so that it can be added to
the appropriate symbol-table entries.

Productions 2 and 3 each evaluate the synthesized attribute T.type,
giving it the appropriate value, integer or float. This type is passed to the
attribute L.inh in the rule for production 1. Production 4 passes L.inh down
the parse tree. That is, the value L1.inh is computed at a parse-tree node by
copying the value of L.inh from the parent of that node; the parent corresponds
to the head of the production.

Productions 4 and 5 also have a rule in which a function addType is
called with two arguments:

id.entry, a lexical value that
points to a symbol-table object, and

L.inh, the type being assigned to
every identifier on the list.

We suppose that function addType
properly installs the type L.inh as the type of the represented
identifier.

A dependency graph for the input
string float idi , i d 2 , i d
3 appears in Fig. 5.9. Numbers 1 through 10 represent the nodes of
the dependency graph.

Nodes 1, 2, and 3 represent the attribute entry associated with each of
the leaves labeled id. Nodes 6, 8, and 10 are the dummy attributes that
represent the application of the function addType to a type and one of these
entry values.

Node 4 represents the attribute *T.type,*
and is actually where attribute eval-uation begins. This type is then passed to
nodes 5, 7, and 9 representing *L.inh*
associated with each of the occurrences of the nonterminal *L. *

**6. Exercises for Section 5.2**

**Exercise 5.2.1 **: What are all the topological
sorts for the dependency graph of Fig. 5.7?

**Exercise 5 . 2 . 2:** For the SDD of Fig. 5.8, give
annotated parse trees for the following expressions:

a) int a, b , c.

b) float w, x, y, z.

**Exercise 5.2.3 : **Suppose that we have a production A
-> BCD. Each of the four nonterminals *A, B, C,* and *D* have two attributes: *s*
is a synthesized attribute, and *i* is
an inherited attribute. For each of the sets of rules below, tell whether *(i)* the rules are consistent with an
S-attributed definition *(ii)* the
rules are consistent with an L-attributed definition, and *(in)* whether the rules are consistent with any evaluation order at
all?

a) *A.s* *-* *B.i + C.s.*

b) *A.s = B.i + C.s* and *D.i
= A.i + B.s.*

c) *A.s* *-* *B.s* *+ D.s.*

! d) *A.s = D.i, B.i =
A.s + C.s, C.i = B.s,* and *D.i =
B.i + C.i.*

**Exercise 5 . 2 . 4: **This grammar generates binary numbers with a "decimal"** **point:

S-* L . L | L

L-+LB1B

B -> 0 | 1

Design an L-attributed SDD to compute *S.val,* the decimal-number value of an input string. For example,
the translation of string 101 . 101 should be the decimal number 5.625. *Hint:* use an inherited attribute *L.side* that tells which side of the
decimal point a bit is on.

**
****Exercise 5 . 2 . 5 **: Design an S-attributed SDD for
the grammar and translation** **described
in Exercise 5.2.4.

**
****Exercise 5 . 2 . 6: **Implement Algorithm 3.23, which converts a regular expression into a
nondeterministic finite automaton, by an L-attributed SDD on a top-down
parsable grammar. Assume that there is a token **char** representing any character, and that *char.lexval* is the character it represents. You may also assume the
existence of a function *new()* that
returns a new state, that is, a state never before returned by this function.
Use any convenient notation to specify the transitions of the NFA.

Study Material, Lecturing Notes, Assignment, Reference, Wiki description explanation, brief detail

Compilers : Principles, Techniques, & Tools : Syntax-Directed Translation : Evaluation Orders for SDD's |

**Related Topics **

Privacy Policy, Terms and Conditions, DMCA Policy and Compliant

Copyright © 2018-2024 BrainKart.com; All Rights Reserved. Developed by Therithal info, Chennai.