SYNTAX DIRECTD TRANSLATION

Objective: To discuss the notational framework known as Syntax Directed Translation (SDT)
Scheme and its applications to generate intermediate code.

In this notes you will find:

• Introduction to SDT, two kinds of attributes

• S-attributed and L-attributed definitions and examples

• Two applications – Syntax trees & Postfix Notations

Introduction:

Syntax directed translation is a notational framework to generate intermediate code and is

an extension of context free grammar(CFG). This framework allows subroutines or semantic
actions to be attached to the productions of CFG. These subroutines can be called when the parser
uses entire production (during expansion in top-down parsers, during reductions in bottom up
parsers). They can perform variety of tasks such as evaluating expressions, generate intermediate
code when called at appropriate times by the parser. The syntax directed translation is useful
because it enables the compiler designer to express the generation of intermediate code directly in
terms of the syntactic structure of the source language.

A syntax-directed definition specifies the values of attributes by associating semantic rules with
the context free grammar productions. For example, an infix-to-post x translator might have a
production and rule

PRODUCTION SEMANTIC RULE

E → E1 + T { E.code = E1.code || T.code || ‘+’ }

This production has two non-terminals, E and T; the subscript in E1 distinguishes the occurrence
of E in the production body from the occurrence of E as the head. Both E and T have a string-
valued attribute code. The semantic rule specifies that the string E.code is formed by concatenating
E1.code, T.code and the character ‘+’. While the rule makes it explicit that the translation of E is
built up from the translations of E1, T, and ‘+’, it may be inefficient to implement the translation
directly by manipulating strings.

A syntax-directed translation scheme embeds program fragments called semantic actions within
production bodies, as

E → E1 + T { print ‘+’; }
By convention, semantic actions are enclosed within curly braces. The position of a semantic
action in a production body determines the order in which the action is executed. in general,
semantic actions may occur at any position in a production body.

Between the two notations, syntax-directed definitions can be more readable, and hence more
useful for specifications. However, translation schemes can be more efficient, and hence more
useful for implementations.

Syntax-Directed Definitions

A syntax-directed definition (SDD) is a context-free grammar together with attributes and rules.
Attributes are associated with grammar symbols and rules are associated with productions. 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. If we implement the nodes of the parse tree by records or objects, then
the attributes of X can be implemented by data fields in the records that represent the nodes for X.
Attributes may be of any kind: numbers, types, table references, or strings, for instance. The strings
may even be long sequences of code, say code in the intermediate language used by a compiler.

There are two types of attributes are used for non-terminals.

1. Synthesized attributes

2. Inherited attributes.

Synthesized attributes: A synthesized attribute for a nonterminal A at a parse-tree node N (a

parent node where A is head/LHS of the production) is defined by a semantic rule associated with
the production at N. A synthesized attribute at node N is de depend only in terms of attribute values
at the children of N (the RHS of production) and on the attribute values of N itself.

Example:

E --> E(1) + T { E.val := E(1).val+ T.val}

E.val is the attribute associated with E on the left hand side of the production and is determined by
adding attribute values on right hand side of the production.

Inherited attributes: An inherited attribute for a nonterminal B at a parse-tree node N is defined

by a semantic rule associated with the production at the parent of N (B is found on the RHS of the
production). An inherited attribute at node N is defined only in terms of attribute values at N's
parent, N itself, and N's siblings.

Example:

A-->XYZ {Y.val=2*A.val}
Y.val is the attribute associated with Y on the right hand side of the production and is determined
by using the attribute value of A on the left hand side of the production.

While we do not allow an inherited attribute at node N to be defined in terms of attribute values at
the children of node N, we do allow a synthesized attribute at node N to be defined in terms of
inherited attribute values at node N itself.

Terminals can have synthesized attributes, but not inherited attributes. Attributes for terminals
have lexical values that are supplied by the lexical analyzer; there are no semantic rules in the SDD
itself for computing the value of an attribute for a terminal.

Example: SDD for evaluating an arithmetic expression

Different types of syntax directed translation(SDT)

1. S-attributed SDT
2. L-attributed SDT.
S-attributed SDT :
An SDD is S-attributed if every attribute is synthesized.
 SDT uses only synthesized attributes.
 S-attributed SDTs are evaluated in bottom-up parsing, as the values of the parent nodes
depend upon the values of the child nodes.
 Semantic actions are placed in rightmost place of RHS.

Example: S-attributed SDD for desk calculator

 Annotated Parse Tree for the expression 3 * 4 + 5

L-attributed SDT:
 an SDD is L Attributed if
1. the attribute may be 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:
(a) Inherited attributes associated with the head A.
(b) Either inherited or synthesized attributes associated with the occurrences of symbols
X1;X2; : : : ;X-1 located to the left of Xi.
(c) 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 Xi.

 Attributes in L-attributed SDTs are evaluated by depth-first and left-to-right parsing

manner.
 Semantic actions are placed anywhere in RHS.
Example: L-attributed SDD for desk calculator

Annotated parse tree for 3 * 5

Example:

A -> XYZ {Y.S = A.S, Y.S = X.S} is an L-attributed definition where as

A -> XYZ {Y.S = A.S, Y.S = X.S, Y.S = Z.S}

is not an L-attributed grammar since Y.S = A.S and Y.S = X.S are allowed but Y.S = Z.S
violates the L-attributed SDT definition as Y is inheriting the value from its right sibling.
Note – If a definition is S-attributed, then it is also L-attributed but NOT vice-versa.
Implementation of syntax directed translation:

Syntax direct translation is implemented by constructing a parse tree and performing the actions
in a left to right depth first order.

Translations on the parse tree: Value associations with a grammar symbol is called the
translation of that symbol. If the translations are represented at the nodes of the parse tree then the
parse tree is called the annotated or decorated parse tree and the process is called annotating or
decorating the parse tree. Annotated parse tree is shown for the sentence 23*5+4$ in figure given
below.

Evaluation Orders for SDD:

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. 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 required to calculate the value of the next

Dependency graph for S-Attributed Definitions:

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 post order
traversal of the parse tree and evaluating the attributes at a node N when the traversal leaves N for
the last time. That is, we apply the function post order, defined below, to the root of the parse tree

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 post order traversal. Specifically, post order corresponds exactly to the order in
which an LR parser reduces a production body to its head.
Example

Dependency Graph for the above production

An example of evaluating 3 +5 * 4 on dependency graph for S attributed Grammar (Discussed

earlier) is given below where the attributes are evaluated in bottom up manner.

Dependency graph for L-Attributed Definitions:

L-attributed definitions allow for a natural order of evaluating attributes: depth-first and left to
right.
An example for L-Attributed Definition with dependency graph is shown in the figure given below

Applications of SDT

The syntax-directed translation techniques will be applied in type checking and intermediate-code
generation. Here, we consider two such examples such as Syntax trees and Postfix notation.

Construction of Syntax Trees:

Syntax tree is a variation of parse tree in which the redundancies (non-terminals) are eliminated in
such a way that the operators becomes the internal nodes and operands becomes the leaves.

Ie., A syntax-tree node representing an expression E1 + E2 has label ‘+’ and two children
representing the subexpressions E1 and E2.

We shall implement the nodes of a syntax tree by objects with a suitable number of fields. Each
object will have an op field that is the label of the node. The objects will have additional fields as
follows:

1. If the node is a leaf, an additional field holds the lexical value for the leaf. A fuction
/constructor Leaf (op, val) creates a leaf node and returns a pointer pointing to the leaf.
2. If the node is an interior/internal node, there are as many additional fields as the node has
children in the syntax tree. A function/constructor Node takes two or more arguments:
Node(op; c1; c2; : : : ; ck) creates an internal node with first field op and k additional fields
for the k children c1; : : : ; ck.

Along with these two functions, all non-terminals have an attribute ‘node’ containing pointer
pointing to either leaf or internal node.

Example: S-attributed SDD for a grammar consisting of + & - operators (whose precedence is
equal)
The simple tracing of bottom up parser for constructing syntax tree for expression “a – 4 + c”

Steps in the construction of syntax tree for the above expression are
Exmple for L-Attributed SDD for the same grammar as follows:

The simple Parser tracing of top-down parser for constructing syntax tree for expression “a – 4 +
c”

Another Application of SDT is Postfix notation:

Some of the compiler designers uses postfix notation as the intermediate representation.

In data structures, you already know postfix expression as the operator is placed after the operands.
Ie., for the infix expression “a + b”, the equivalent postfix expression is “a b +”

Now we design S-attributed SDD for converting an infix expression into postfix expression.
Here we use an attribute “code” which is string based used to contain the string of the
corresponding postfix form for the non-terminal.

Sl no Production Semantic Rule Semantic Action

1 L→En { L.code = E.code } -
2 E → E1 + T {E.code = E1.code||T.code ||’ + ‘} “ print ‘+’ “
3 E→T {E.code = T.code } -
4 T → T1 * F {T.code = T1.code||F.code ||’ * ‘} “ print ‘*’ “
5 T→F {T.code = F.code} -
6 F→(E) {F.code = E.code} -
7 F → digit {F.code = digit.lexval} “ print ‘a’ “

Example: Convert a +b * c into postfix form by simple bottom up parser.

Stack Input Action Output

$ a+b*c$ S(a)
$a +b*c$ R(a) & R(F,T) a
$F , T, E +b*c$ S(+,b)
$E+b *c$ R(b)& R(F) b
$E+ T *c$ S(*, c) c
$E + T * c $ R(c) & R(F)
$E+T*F $ R(T*F) *
$E+T $ R(E+T) +
$E $ Accepted abc*+

So, the final output by the parser is “a b c * + “ which is the postfix equivalent of “ a + b * c”.

*********************************ALL THE BEST *******************************