Lecture5 - Syntax Directed Translation
Lecture5 - Syntax Directed Translation
Introduction
• A syntax-directed definition specifies the values of attributes by associating
semantic rules with the grammar productions
• An infix-to-postfix translator might have a production & rule
• 02 non-terminals: E , T
• subscript in E1 distinguishes the occurrence of E in the production body from
the occurrence of E as the head;
• Both E & T have a string-valued attribute code.
• The semantic rule specifies that the string E.code is formed by concatenating
E1 . code, T. code, & the character ' +'.
• While the rule makes it explicit that the translation of E is built up from the
translations of E1 , T, & '+', 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 in
Syntax-directed definitions:
can be more readable
hence more useful for specifications.
Translation schemes
can be more efficient
hence more useful for implementations.
Approaches
Syntax-directed translation
• construct a parse tree or a syntax tree , and then to compute the
values of attributes at the nodes of the tree by visiting the nodes
of the tree.
Translation Schemes
• translation can be done during parsing, without building an
explicit tree.
"L-attributed translations" (L for left-to-right), which encompass
virtually all translations that can be performed during parsing.
"S-attributed translations" (S for synthesized) , which can be
performed easily in connection with a bottom-up parse.
Syntax-Directed Definitions (SDD)
is a CFG together with attributes & rules.
Attributes are associated with grammar symbols & 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.
Inherited vs. Synthesized Attributes
Example:
S-Attributes:
L.val, E.val, T.val, F.val
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 & evaluating the
attributes at a node N when the
traversal leaves N for the last time.
L-Attributes Definitions
• 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" ) .
Characteristics( each attribute must be either):
1. Synthesized, or
2. Inherited, but with the rules limited as follows . Suppose that there
is a production A X1X2 …. 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, …. Xi-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
The first of these rules defines the inherited attribute T’.inh using only
F.val, & F appears to the left of T' in the production body
The second rule defines T`1.inh using the inherited attribute T’.inh
associated with the head, and F.val, where F appears to the left of T`1.inh
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.
Semantic Rules with Controlled Side Effects
• More precisely,
If the parse is bottom-up, then we perform action a as soon
as this occurrence 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 non-terminal) or
check for Y on the input (if Y is a terminal) .
Any SDT can be implemented
1. Ignoring the actions, parse the input & produce a
parse tree as a result.
2. Then, examine each interior node N, say one for
production A . Add additional children to N
for the actions in , so the children of N from left
to right have exactly the symbols & actions of
3. Perform a preorder traversal of the tree, and as
soon as a node labeled by an action is visited,
perform that action.
Preorder: action is done when
we first Visit a node