Syntax Directed Translation

1
➢We associate information with a language construct by attaching attributes to the
grammar symbol(s) representing the construct
➢A syntax-directed definition specifies the values of attributes by associating
semantic rules with the grammar productions.
➢For example, an infix-to-postfix translator might have a production and rule

➢A syntax-directed translation scheme embeds program fragments called semantic

actions within production bodies, as in

2
Syntax-Directed Definitions (SDD)
➢A syntax-directed definition (SDD) is a context-free grammar together with
attributes and rules.
▪ Attributes are associated with grammar symbols
▪ Rules are associated with productions
▪ Attributes may be of any kind: numbers, types, table references, or
strings, for instance.
➢If X is a symbol and a is one of its attributes, then we write X.a to denote
the value of a at a particular parse-tree node labeled X.

3
Kinds of attributes in SDD
➢Synthesized attribute : A synthesized attribute at node N is defined only in
terms of attribute values at the children of N and at N itself.

➢Inherited attribute : An inherited attribute at node N is defined only in

terms of attribute values at N's parent, N itself, and N's siblings.

4
SDD of a simple desk calculator

Side Effect: prints the value E.val

as a side effect, instead of defining
the attribute L.val.
➢ SDD without side effects is
sometimes called attribute grammar

5
S-Attributed SDD
➢An SDD that involves only synthesized attributes is called S-attributed
➢Each rule computes an attribute at the head from the body of the
production
➢An S-attributed SDD can be implemented naturally in conjunction with an
LR parser.
➢Yacc program prints the value E.val as a side effect, instead of defining the
attribute L.val.
➢An SDD without side effects is sometimes called an attribute grammar.

6
Evaluating an SDD at the Nodes of a Parse Tree
➢A parse tree, showing the value(s) of its attribute(s) is called an annotated parse
tree.
➢How do we construct an annotated parse tree? In what order do we evaluate
attributes?
➢ For synthesized attributes, we can evaluate attributes in any bottom-up order,
▪ such as that of a postorder traversal of the parse tree;
➢For SDD's with both inherited and synthesized attributes, there is no guarantee
that there is even one order in which to evaluate attributes at nodes.
▪ Ex. circular dependency

7
Annotated parse tree for 3 * 5 + 4 n

8
An SDD based on a grammar (non-left-recursive) suitable
for top-down parsing

❖ Inherited attributes are useful when the

A Parse tree for expression 3*5
structure of a parse tree does not "match"
the abstract syntax of the source code.
9
Evaluation Orders for SDD's
➢Dependency Graphs
➢Ordering the Evaluation of Attributes
➢S-Attributed Definitions
➢L-Attributed Definitions
➢Semantic Rules with Controlled Side Effects

10
Dependency Graphs
➢A dependency graph depicts the flow of information among the attribute
instances in a particular parse tree;
▪ For a node X, the dependency graph has a node for each attribute associated with X.
▪ If a production p defines the value of
• synthesized attribute A.b in terms of the value of X.c, then, the dependency graph has an
edge from X.c to A.b.
• 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.

❑ parse tree edges as dotted lines

❑ edges of the dependency graph
are solid.

11
An example of a complete dependency graph

Topological sort: 1, 3, 5, 2, 4, 6, 7, 8, 9.
12
Ordering the Evaluation of Attributes
➢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.
▪ Orders of evaluation of nodes N , N ,…. N such that if there is an edge of the
,
dependency graph from 𝑁 to 𝑁 then i<j.
▪ a linear order, and is called a topological sort
➢If there is any cycle in the graph, then there are
▪ no topological sorts
▪ no way to evaluate the SDD
➢If there are no cycles,
▪ then there is always at least one topological sort.
➢If there is any cycle in the graph, then

13
Removing Cycle
➢If there is any cycle in the graph, then
▪ Traverse from predecessor to predecessor until we came back to some node we had
already seen
▪ Make this node the first in the topological order
▪ Remove it from the dependency graph
▪ Repeat the process on the remaining nodes.

14
SDD
➢given an SDD, it is very hard to tell whether there exist any parse trees
whose dependency graphs have cycles.
➢translations can be implemented using classes of SDD's that guarantee an
evaluation order, since they do not permit dependency graphs with cycles

➢Two Classes of SDDs

▪ S-Attributed
▪ L-Attributed

15
S-Attributed Definitions
➢An SDD is S-attributed if every attribute is synthesized.
▪ Ex. Each attribute, L.val, E.val, T.val, and F.val is synthesized
➢S-attributed SDD is evaluated
▪ bottom up order
▪ a post order traversal
▪ Like as LR parser that reduces
a production body to its head.
▪ without creating the tree nodes
explicitly.

16
L-Attributed Definitions
➢Dependency-graph edges can go from left to right, but not from right to left
➢Each attribute must be either

17
L-Attributed SDD’s Example

➢T' .inh using only F.val, and F appears to the left of T' in the production
body
➢defines 𝑇 .inh using the inherited attribute T' .inh associated with the head,
and F.val, appears to the left of 𝑇 .
➢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.
18
Checking SDD as an S-attributed or L attributed

➢ The first rule, A.s = B.b, is in either an S-attributed or L attributed SDD.

➢ The second rule defines an inherited attribute B.i, so the entire SDD
cannot be S-attributed.
➢ Attribute C.c defines B.i, and is right of B in the production body.
So, SDD cannot be L-attributed.
➢ In L-attributed SDD's, attributes at siblings have to be the left of the
symbol whose attribute is being defined.

19
Semantic Rules with Controlled Side Effects
➢Side Effects are
▪ A desk calculator might print a result
▪ A code generator might enter the type of an identifier into a symbol table
➢Controlling side effects of SDD’s
▪ Permit incidental side effects that do not constrain attribute evaluation.
▪ Constrain the allowable evaluation orders, such as implicit edges added to the
dependency graph.
➢Example of an incidental side effect
▪ Instead of the rule L.val = E.val, use
▪ print(E.val) is dummy synthesized attributes.
▪ Since the print statement is executed at the end, no change of topological sort.

20
Syntax-directed definition for simple type declarations

Dependency graph for a declaration float id1 , id2 , id3

21
Applications of Syntax-Directed Translation
➢Type checking and intermediate-code generation
➢Construction of Syntax Trees
▪ SDD’s are considered for constructing syntax trees for expressions
• S-attributed SDD’s for bottom-up parsing
• L-attributed SDD’s for top-down parsing.
➢The Structure of a Type

22
Construction of Syntax Trees (Bottom up)

Steps in the construction of the

syntax tree for a - 4 + c
S-attributed SDT

23
Syntax tree for a-4 + c

24
Construction of Syntax Trees (Top Down)

L-Attributed SDD Dependency graph for a-4+c

25
The Structure of a Type
➢Inherited attributes are useful
▪ when the structure of the parse tree differs from the abstract syntax
➢A mismatch in structure
▪ Due to the design of the language
▪ Not due to constraints imposed by the parsing method.
➢EX:
▪ the type int [2][3] can be read as, "array of 2 arrays of 3 integers.“
▪ expression array(2, array(3, integer)) is represented by the f o llo win g tree

26
SDT of array types

27
Syntax-Directed Translation Schemes
➢All applications of SDD can be implemented using SDT schemes.
➢SDT is a context free grammar with program fragments embedded within
production bodies.
➢Program fragments, called semantic actions appear at any position within
a production body.
➢Place curly braces as grammar symbols, then quote them.
➢SDT implemented by first building a parse tree and then per forming the
actions
▪ left-to-right
▪ depth-first order
▪ during a preorder traversal

28
SDT Schemes
➢Two important classes of SDD’s:
▪ The underlying grammar is LR-parsable, and the SDD is S-attributed.
▪ The underlying grammar is LL-parsable, and the SDD is L-attributed.

29
Postfix Translation Schemes
➢SDT's with actions at right ends of production bodies,called postfix SDT’s.
➢It is implemented using S-attributed SDD.
➢Bottom up parsing
➢Each action is placed at the end of the production
➢Reduction of the body to the head
➢Example: Postfix SDT implementing the desk calculator

30
Parser-Stack Implementation of Postfix SDT's
➢Postfix SDT's can be implemented during LR parsing by executing the
actions when reductions occur.
➢The attribute(s) are put on the stack where they can be found during the
reduction
➢Place the attributes along with the grammar symbols in records on the
stack itself

A→XYZ

31
Implementing desk calculator on bottom-up parsing stack

32
SDT's With Actions Inside Productions
➢An action placed at any position within the body of a production.
➢It is performed immediately after all symbols to its left are processed.
➢If we have a production B → X {a} Y, the action a is done after we have
recognized X (if X is a terminal) or all the terminals derived from X (if X is a
nonterminal).
➢More precisely,
▪ If the parse is bottom-up, then we perform action a as soon as this oc currence of X
appears on the top of the parsing stack.
▪ If the parse is top-down, we perform a just before we attempt to expand this
occurrence of Y (if Y a nonterminal) or check for Y on the input (if Y is a terminal).
➢SDT's that can be implemented during parsing include
▪ postfix SDT’s
▪ a class of SDT's that implements L-attributed definitions.

33
Problematic SDT for infix-to-prefix translation during
parsing
➢An SDT that prints the prefix form of an expression, rather than evaluating
the expression.

➢Unfortunately, it is impossible to implement this SDT during either top

down or bottom-up parsing, because the parser would have to perform
critical actions, like printing instances of * or +, long before it knows
whether these symbols will appear in its input.

34
Any SDT can be implemented as follows:
➢1. Ignoring the actions, parse the input and produce a parse tree as a
result.
➢2. Then, examine each interior node N, say one for production A a. Add
additional children to N for the actions in a, so the children of N from left to
right have exactly the symbols and actions of a.
➢3. Perform a preorder traversal (see Section 2.3.4) of the tree, and as
soon as a node labeled by an action is visited, perform that action.

35
Parse tree with actions embedded
➢For expression 3* 5 + 4 with prefix form of the expression: + * 3 5 4.

36