0% found this document useful (0 votes)
12 views

SDT v1

Uploaded by

naga
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
12 views

SDT v1

Uploaded by

naga
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 46

Syntax-Directed Translation

The Phases of a Compiler


Syntax-Directed Translation

• Semantic analysis and


translation actions can
be interlinked with
parsing

• Implemented as a
single module.
Syntax-Directed Translation

• Translation of languages guided by context-free


grammars.

• Attach attributes to the grammar symbol

• Syntax-directed definition specifies the values of


attributes
• By associating semantic rules with the grammar
productions
Syntax-Directed Translation
• 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.

• If X is a grammar symbol and a is one of its attributes,


• X.a denotes the value of the attribute X.

• Attributes may be
• numbers, types, table references, or strings,
• Strings may even be code in the intermediate language.
Attributes

Synthesized attribute:
• Synthesized attribute for a nonterminal A at a parse-tree node N
is defined by
• Semantic rule associated with the production at N.
• The production must have A as its head.

• A synthesized attribute at node N is defined only in terms of


attribute values at the children of N and at N itself.
Attributes
Inherited attribute:
• Inherited attribute for a nonterminal B at a parse-tree node N
is defined by

• Semantic rule associated with the production at the parent


of N

• Note that the production must have B as a symbol in its body.

• An inherited attribute at node N is defined only in terms of


attribute values at N's parent, N itself, and N's siblings
Attributes

• Synthesized attribute at node N to be defined in terms of


inherited attribute values at node N itself.

• Do not allow an inherited attribute at node N to be defined in


terms of attribute values at the children of node N

• Terminals can have synthesized attributes, but not inherited


attributes.
• Attributes for terminals have lexical values that are supplied by
the lexical analyzer
Example of SDD
Each of the Non-terminals has a single synthesized
attribute, called val
Annotated parse tree.
A parse tree, showing the value(s) of its attribute(s) is called
an annotated parse tree.
Input string: 3 * 5 + 4 n

• We show the resulting values


associated with each node.

• Each of the nodes for the


nonterminals has attribute val
computed in a bottom-up order,
Annotation and Evaluation of parse tree
Annotated parse tree.
val and syn: Synthesized
inh: Inherited

Annotated parse tree


for 3 * 5

1 3
6
4
2 5
Evaluation Orders of SDD
• "Dependency graphs" are a useful tool for determining an
evaluation order for the attribute instances in a given parse tree.
• Depicts the flow of information among the attribute
instances in a particular parse tree
• Directed edges

• For a node A in parse tree -> node A in dependency graph

A has a synthesized attribute b


Production Semantic Rule
A->…X.. A.b=f(.., X.c, ..)
• Edge from X.c to A.b
• Edge from child attribute to parent attribute
Evaluation Orders of SDD
• "Dependency graphs" are a useful tool for determining an
evaluation order for the attribute instances in a given parse tree.
• Depicts the flow of information among the attribute
instances in a particular parse tree
• Directed edges
• For a node A in parse tree -> node A in dependency graph

B has an inherited attribute c


Production Semantic Rule
A->…B..X.. B.c=f(.., X.a, ..)
• Edge from X.a to B.c
• Edge from attribute a of X (parent or sibling of B) to
attribute c of B (body of the production)
Annotated parse tree for 3 * 5
Ordering the Evaluation of Attributes
• The dependency graph characterizes the possible evaluation orders
• In which we can evaluate the attributes at the various nodes of a
parse tree.

• If the dependency graph has an edge from node M to node N,


• Attribute corresponding to M must be evaluated before the
attribute of N.

• If there is an edge of the dependency graph from Ni to Nj, such that i < j
• the only allowable orders of evaluation are those sequences of
nodes N1, N2,... ,Nk

• Embeds a directed graph into a linear order, and is called a topological


sort of the graph
Topological Sort- Ordering the Evaluation

• One topological sort is the order in which the nodes have already
been numbered: 1,2,... ,9.

• There are other topological sorts as well, such as 1,3,5,2,4,6,7,8,9.


Ordering the Evaluation – Cycles

These rules are circular; it is impossible to


evaluate either A.s or B.i
Classes of SDD

(a) S-Attributed Definitions


(b) L-Attributed Definitions

Guarantee an evaluation order


S-Attributed SDD

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


L-Attributed SDD
• The idea behind L-attributed SDD 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")
L-Attributed SDD
Side Effects
• Print a result,
• Enter the type of an identifier into a symbol table.
Side Effects – examples
• The SDD 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.

The type is passed to the attribute L.inh

Evaluate the synthesized attribute T.type,


giving it the appropriate value, integer or float.
Passes L.inh down the parse tree
Function addType() properly installs the
type L.inh as the type of the identifier.
Side Effects
Declaration statement
Representing data types: Type Expressions

Types have structure, which we shall represent using type


expressions.

• A type expression is either a basic type (boolean, char, integer,


float, and void)
or
• is formed by applying an operator called a type constructor to a
type expression.
• A type expression can be formed by applying the array type
constructor to a number and a type expression.
Declaration statement
• The array type int [2] [3] can be read as "array of 2
arrays of 3 integers each"
• Can be represented as a type expression array(2,
array(3, integer)).
• This type is represented by the tree.

• The operator array takes two parameters, a number


and a type.
• Here the type expression can be formed by
applying the array type constructor to a number
and a type expression.
Declaration statement
Example SDD

Type Expressions

• Nonterminal T generates either a basic type or an array type.


• Nonterminal B generates one of the basic types int and float.
• T generates a basic type when C derives €.
• Otherwise, C generates array components consisting of a sequence of
integers, each integer surrounded by brackets.
Declaration statement
Example SDD

Type Expressions

• The nonterminals B and T have a synthesized attribute t


representing a type.
• The nonterminal C has two attributes: an inherited attribute b
and a synthesized attribute t.
Declaration statement
Example SDD
input string int [2][3]

• The nonterminal C has two attributes: an inherited attribute b


and a synthesized attribute t.
• The inherited b attributes pass a basic type down the tree, and
the synthesized t attributes accumulate the result.
Application of SDD – Syntax tree
construction
• Each node in a syntax tree represents a construct; the children of
the node represent the meaningful components of the construct.

• A syntax-tree node representing an expression E1 + E2 has label +


and two children representing the subexpressions E1 and E2
Application of SDD – Syntax tree
construction
Application of SDD – Syntax tree
construction
• Each node in a syntax tree represents a construct; the children of
the node represent the meaningful components of the construct.

• A syntax-tree node representing an expression E1 + E2 has label +


and two children representing the subexpressions E1 and E2
Application of SDD – Syntax tree
construction
Application of SDD – Syntax tree
construction

If the rules are evaluated during a


postorder traversal of the parse tree,
or
with reductions during a bottom-up
parse, then the sequence of steps
Syntax-Directed Translation Schemes

• Syntax-directed translation schemes are a complementary notation to syntax


directed definitions.

• All of the applications of syntax-directed definitions can be implemented using


syntax-directed translation schemes.

• Syntax-directed translation scheme (SDT) is a context free grammar with


program fragments embedded within production bodies.

• The program fragments are called semantic actions and can appear at any
position within a production body.
Syntax-Directed Translation Schemes

• The simplest SDD implementation occurs when we can parse the grammar
bottom-up and the SDD is S-attributed.
• In that case, we can construct an SDT in which each action is placed at the end
of the production
• Executed along with the reduction of the body to the head of that
production.
• SDT's with all actions at the right ends of the production bodies are called
postfix SDT’s.
Syntax-Directed Translation Schemes
Parser Implementation of Postfix SDT's

• Postfix SDT's can be implemented during LR parsing by executing


the actions when reductions occur.

• The attribute(s) of each grammar symbol can be put on the stack in


a place where they can be found during the reduction.

• The parser stack contains records with a field for a grammar symbol
(or parser state) and, below it, a field for an attribute

The three grammar symbols X Y Z


are on top of the stack.

Perhaps they are about to be


reduced according to a production
like A->X Y Z
Parser Implementation of Postfix SDT's

A->X Y Z
• If the attributes are all synthesized, and the actions occur at the ends
of the productions
• then we can compute the attributes for the head when we
reduce the body to the head.

• If we reduce by a production such as A -> X Y Z, then


• we have all the attributes of X, Y, and Z available, at known
positions on the stack.

• After the action, A and its attributes are pushed at the top of the stack,
in the position of the record for X
Actions of the desk-
calculator SDT so that
they manipulate the
parser stack explicitly
SDT's With Actions Inside Productions
SDT for infix-to-prefix translation during parsing

• It is impossible to implement this SDT during either topdown or


bottom-up parsing,
• because the parser would have to perform semantic
actions, like printing instances of * or +,
• long before it knows whether these symbols will appear in
its input .
If we visit the nodes in preorder,
we get the prefix form of the
expression: + * 3 5 4

You might also like