Syntax-Directed Translation

CS308 Compiler Theory 1

 Syntax-Directed Translation
• Grammar symbols are associated with attributes to associate
information with
ith the programming language
lang age constructs
constr cts that they
the
represent.
• Values of these attributes are evaluated by the semantic rules
associated with the production rules.
• Evaluation of these semantic rules:
– may generate intermediate codes
– may put information into the symbol table
– mayy pperform type
yp checkingg
– may issue error messages
– may perform some other activities
– in fact, they may perform almost any activities.
• An attribute may hold almost any thing.
– a string, a number, a memory location, a complex record.

CS308 Compiler Theory 2

Syntax-Directed Definitions and Translation Schemes
• When we associate semantic rules with productions, we use two
notations:
i
– Syntax-Directed Definitions
– Translation Schemes
• Syntax-Directed Definitions:
– give high-level specifications for translations
– hide many implementation details such as order of evaluation of semantic actions.
– We associate a pproduction rule with a set of semantic actions, and we do not sayy when theyy
will be evaluated.
• Translation Schemes:
– iindicate
di the
h order
d off evaluation
l i off semantic i actions
i associated
i d with
i h a production
d i rule.
l
– In other words, translation schemes give a little bit information about implementation
details.

CS308 Compiler Theory 3

 Syntax-Directed Definitions
• A syntax-directed definition is a generalization of a context-free
grammar in
i which:
hi h
– Each grammar symbol is associated with a set of attributes.
– This set of attributes for a grammar symbol is partitioned into two subsets called
synthesized and inherited attributes of that grammar symbol.
– Each production rule is associated with a set of semantic rules.
• Semantic rules set up dependencies between attributes which can be
represented by a dependency graph.
• This dependency graph determines the evaluation order of these
semantic rules.
• Evaluation of a semantic rule defines the value of an attribute. But a
semantic rule may also have some side effects such as printing a value.

CS308 Compiler Theory 4

 Annotated Parse Tree
• A parse tree showing the values of attributes at each node is called
an annotated parse tree.
• The process of computing the attributes values at the nodes is called
t ti (or
annotating ( decorating)
d ti ) off the
th parse tree.
t
• Of course, the order of these computations depends on the
dependency graph induced by the semantic rules.
rules

CS308 Compiler Theory 5

 Syntax-Directed Definition
• In a syntax-directed definition, each production A→α is associated
with
i h a set off semantic
i rules
l off the
h form:
f
b=f(c1,c2,…,cn) where f is a function,
and b can be one of the followings:
Î b is a synthesized attribute of A and c1,c2,…,cn are attributes of the
grammar symbolsb l in
i the
th production
d ti ( A→αA )
).
OR
Î b is i an inherited
i h i d attribute
ib one off the h grammar symbolsb l in
i α (on
( the h
right side of the production), and c1,c2,…,cn are attributes of the
grammar symbolsb l in
i the
th production
d ti ( A→αA )
).

CS308 Compiler Theory 6

 Attribute Grammar
• So, a semantic rule b=f(c1,c2,…,cn) indicates that the attribute b
d d on attributes
depends ib c1,c2,…,cn.
• In a syntax-directed definition, a semantic rule may just evaluate
a value
l off an attribute
tt ib t or it may have
h some side
id effects
ff t suchh as
printing values.

• An attribute grammar is a syntax-directed definition in which the

functions in the semantic rules cannot have side effects (they can
only evaluate values of attributes).

CS308 Compiler Theory 7

 Syntax-Directed Definition -- Example
Production Semantic Rules
L → E return print(E.val)
E → E1 + T E.val = E1.val + T.val
E→T E.val = T.val
T → T1 * F T.val = T1.val * F.val
T→F T l = F.val
T.val F l
F→(E) F.val = E.val
F → digit F val = digit.lexval
F.val digit lexval

• Symbols E,
E T,
T and F are associated with a synthesized attribute val.
val
• The token digit has a synthesized attribute lexval (it is assumed that it is
evaluated by the lexical analyzer).

CS308 Compiler Theory 8

 Annotated Parse Tree -- Example
Input: 5+3*4 L

E.val=17 return

E.val=5 + T.val=12

T.val=5 T.val=3 * F.val=4

F.val=5 F.val=3 digit.lexval=4

digit.lexval=5 digit.lexval=3

CS308 Compiler Theory 9

 Dependency Graph
Input: 5+3*4 L

E.val=17

E.val=5 T.val=12

T.val=5 T.val=3 F.val=4

F.val=5 F.val=3 digit.lexval=4

digit.lexval=5 digit.lexval=3

CS308 Compiler Theory 10

 Syntax-Directed Definition – Example2
Production Semantic Rules
E → E1 + T E.loc=newtemp(),
E l () E.code
E d = E1.code d || TT.code
d || add
dd E1.loc,T.loc,E.loc
l Tl El
E→T E.loc = T.loc, E.code=T.code
T → T1 * F T.loc=newtemp(),
p(), T.code = T1.code || F.code || mult T1.loc,F.loc,T.loc
, ,
T→F T.loc = F.loc, T.code=F.code
F→(E) F.loc = E.loc, F.code=E.code
F → id F l = id.name,
F.loc id F d “”
F.code=“”

• Symbols E,E T,
T and F are associated with synthesized attributes loc and
code.
• The token id has a synthesized attribute name (it is assumed that it is
evaluated by the lexical analyzer).
• It is assumed that || is the string concatenation operator.

CS308 Compiler Theory 11

 Syntax-Directed Definition – Inherited Attributes

Production Semantic Rules

D→TL L.in = T.type
T → int T.type = integer
T → real T.type = real
L → L1 id L1.in = L.in, addtype(id.entry,L.in)
yp ( y )
L → id addtype(id.entry,L.in)

• Symbol T is associated with a synthesized attribute type.

• Symbol L is associated with an inherited attribute in.

CS308 Compiler Theory 12

 A Dependency Graph – Inherited Attributes
Input: real p q

D L.in=real

T L T.type=real L1.in=real addtype(q,real)

real L id addtype(p,real) id.entry=q

id id.entry=p

pparse tree dependency

p y graph
g p

CS308 Compiler Theory 13

 S-Attributed Definitions
• Syntax-directed definitions are used to specify syntax-directed translations.
• T create a translator
To l for
f an arbitrary
bi syntax-directed
di d definition
d fi i i can be b difficult.
diffi l
• We would like to evaluate the semantic rules during parsing (i.e. in a single pass, we
will p
parse and we will also evaluate semantic rules during
g the pparsing).
g)
• We will look at two sub-classes of the syntax-directed definitions:
– S-Attributed Definitions: only synthesized attributes used in the syntax-directed
definitions.
definitions
– L-Attributed Definitions: in addition to synthesized attributes, we may also use inherited
attributes in a restricted fashion.
• To implement S-Attributed Definitions and L-Attributed Definitions are easy (we can
evaluate semantic rules in a single pass during the parsing).
• Implementations of SS-attributed
attributed Definitions are a little bit easier than implementations
of L-Attributed Definitions

CS308 Compiler Theory 14

 Bottom-Up Evaluation of S-Attributed Definitions
• We put the values of the synthesized attributes of the grammar symbols into a parallel
stack.
stack
– When an entry of the parser stack holds a grammar symbol X (terminal or non-terminal),
the corresponding entry in the parallel stack will hold the synthesized attribute(s) of the
symbol
b l X.
X
• We evaluate the values of the attributes during reductions.

A → XYZ A.a=f(X.x,Y.y,Z.z) where all attributes are synthesized.

stack parallel-stack
top → Z Z.z
Y Y.y
X X.x Î top → A A.a
. . . .
CS308 Compiler Theory 15
 Bottom-Up Eval. of S-Attributed Definitions (cont.)
Production Semantic Rules
L → E return print(val[top-1])
E → E1 + T val[ntop] = val[top-2] + val[top]
E→T
T → T1 * F val[ntop] = val[top-2] * val[top]
T→F
F→(E) val[ntop] = val[top-1]
F → digit
• At each shift of digit, we also push digit.lexval into val-stack.
• At
A all
ll other
h shifts,
hif we do d not put anything
hi into
i val-stack
l k because
b
other terminals do not have attributes (but we increment the
stack pointer for val
val-stack).
stack).

CS308 Compiler Theory 16

 Canonical LR(0) Collection for The Grammar
.. L I1: L’→L . . .
I0: L’→
.
L I7: L →Er I11: E →E+T * 9

.. .. .
L→ Er r T
E T →T *F
E→
E→
..
E+T
T
I2: L →E r
E →E +T
+ I8: E →E+ T
T → T*F .. (
F 4
5
T→
T→
F→..
T*F
F
(E)
T I3: E →T ..
T →T *F
T→ F
F → (E)
F→ d
( ) .. d
6

F→ d
F I4: T →F . *

.
. I9: T →T* F
..
F
I12: T →T*F .
..
( I5: F → ( E) F → (E)
(
E→ E+T E
F→ d 5

..
E→ T d
6
T→
T→
F→..
T*F
F
(E)
T
3
I10: F →(E )
E →E
E +T
.. +
) I13: F →(E) .
F→ d F
4 8
d I6: F →d . (
d
5
6

CS308 Compiler Theory 17

 Bottom-Up Evaluation -- Example
• At each shift of digit, we also push digit.lexval into val-stack.
stack val stack
val-stack input action semantic rule
0 5+3*4r s6 d.lexval(5) into val-stack
0d6 5 +3*4r F→d F.val=d.lexval – do nothing
0F4 5 +3*4r T→F T val=F val – do nothing
T.val=F.val
0T3 5 +3*4r E→T E.val=T.val – do nothing
0E2 5 +3*4r s8 push empty slot into val-stack
0E2+8 55- 33*4r
4r s6 d lexval(3) into val
d.lexval(3) val-stack
stack
0E2+8d6 5-3 *4r F→d F.val=d.lexval – do nothing
0E2+8F4 5-3 *4r T→F T.val=F.val – do nothing
0E2+8T11
0E2 8T11 55-33 *4r
4r s9 push empty slot into val
val-stack
stack
0E2+8T11*9 5-3- 4r s6 d.lexval(4) into val-stack
0E2+8T11*9d6 5-3-4 r F→d F.val=d.lexval – do nothing
0E2+8T11*9F12 5-3-4 r T→T*F T.val=T1.val*F.val
0E2+8T11 5-12 r E→E+T E.val=E1.val*T.val
0E2 17 r s7 push empty slot into val-stack
0E2r7 17- $ L→Er pprint(17),
( ) pop
p p empty
p y slot from val-stack
0L1 17 $ acc
CS308 Compiler Theory 18
 Top-Down Evaluation (of S-Attributed Definitions)
Productions Semantic Rules
A→B print(B.n0), print(B.n1)
B → 0 B1 B.n0=B1.n0+1, B.n1=B1.n1
B → 1 B1 B.n0=B1.n0, B.n1=B1.n1+1
B→ε B.n0=0, B.n1=0

where B has two synthesized attributes (n0 and n1).

CS308 Compiler Theory 19

 Top-Down Evaluation (of S-Attributed Definitions)
• Remember that: In a recursive predicate parser, each non-terminal
corresponds to a procedure.
proced re

procedure A() {
call B(); A→B
}
procedure B() {
if ((currtoken=0)) { consume 0;; call B();
(); } B→0B
else if (currtoken=1) { consume 1; call B(); } B→1B
else if (currtoken=$) {} // $ is end-marker B→ε
else error(“unexpected token”);
}

CS308 Compiler Theory 20

 Top-Down Evaluation (of S-Attributed Definitions)
procedure A() {
int n0,n1;
n0 n1; Synthesized attributes of non-terminal
non terminal B
call B(&n0,&n1); are the output parameters of procedure B.
pprint(n0);
( ); print(n1);
p ( );
} All the semantic rules can be evaluated
procedure B(int *n0, int *n1) { at the end of parsing of production rules
if (currtoken=0)
{int a,b; consume 0; call B(&a,&b); *n0=a+1; *n1=b;}
else if (currtoken=1)
{ int a,b; consume 1; call B(&a,&b); *n0=a; *n1=b+1; }
else if ((currtoken=$)) {{*n0=0; *n1=0; } // $ is end-marker
else error(“unexpected token”);
}

CS308 Compiler Theory 21

 L-Attributed Definitions
• S-Attributed Definitions can be efficiently implemented.
• We are looking for a larger (larger than S-Attributed Definitions) subset
of syntax-directed definitions which can be efficiently evaluated.
Î L-Attributed Definitions

• L-Attributed Definitions can always be evaluated by the depth first visit

of the parse tree.
• This
Thi means thath they
h can also
l beb evaluated
l d during
d i the h parsing.
i

CS308 Compiler Theory 22

 L-Attributed Definitions
• A syntax-directed definition is L-attributed if each inherited attribute
of Xj, where 1≤j≤n, on the right side of A → X1X2...Xn depends only
on:
1 The
1. Th attributes
tt ib t off the
th symbols
b l X1,...,X
Xj-1 to
t the
th left
l ft off Xj in
i the
th
production and
2 the inherited attribute of A
2.

• Every S-attributed
S attributed definition is L-attributed,
L attributed the restrictions only apply
to the inherited attributes (not to synthesized attributes).

CS308 Compiler Theory 23

 A Definition which is NOT L-Attributed
Productions Semantic Rules
A→LM L.in=l(A.i), M.in=m(L.s), A.s=f(M.s)
A→QR R.in=r(A.in), Q.in=q(R.s), A.s=f(Q.s)

• This syntax-directed definition is not L-attributed because the semantic

rule Q.in=q(R.s) violates the restrictions of L-attributed definitions.
• When Q.in must be evaluated before we enter to Q because it is an
i h i d attribute.
inherited ib
• But the value of Q.in depends on R.s which will be available after we
return
t from
f R.
R So,
S we are nott be
b able
bl to
t evaluate
l t the
th value
l off Q.in
Qi
before we enter to Q.

CS308 Compiler Theory 24

 Translation Schemes
• In a syntax-directed definition, we do not say anything about the
evaluation
l i times
i off the
h semantici rules
l (when
( h theh semantici rules
l
associated with a production should be evaluated?).

• A translation scheme is a context-free grammar in which:

– attributes
tt ib t are associated
i t d with
ith the
th grammar symbols
b l andd
– semantic actions enclosed between braces {} are inserted within
the right sides of productions.
productions

• Ex:
E A → { ... } X { ... } Y { ... }

S
Semantic
ti Actions
A ti
CS308 Compiler Theory 25
 Translation Schemes
• When designing a translation scheme, some restrictions should be
observed
b d to ensure that
h an attribute
ib valuel is
i available
il bl when
h a semantic i
action refers to that attribute.
• These
Th restrictions
t i ti (motivated
( ti t d by b L-attributed
L tt ib t d definitions)
d fi iti ) ensure that
th t
a semantic action does not refer to an attribute that has not yet
computed.
computed
• In translation schemes, we use semantic action terminology instead of
semantic rule terminology gy used in syntax-directed
y definitions.
• The position of the semantic action on the right side indicates when that
semantic action will be evaluated.

CS308 Compiler Theory 26

 Translation Schemes for S-attributed Definitions
• If our syntax-directed definition is S-attributed, the construction of
the
h corresponding
di translation
l i scheme
h will
ill be
b simple.
i l
• Each associated semantic rule in a S-attributed syntax-directed
d fi iti will
definition ill be
b inserted
i t d as a semantic
ti action
ti into
i t the
th endd off the
th
right side of the associated production.
Production Semantic Rule
E → E1 + T E.val = E1.val + T.val Î a production of
a syntax directed definition

⇓
E → E1 + T { E.val = E1.val + T.val } Î the production of the corresponding
translation scheme

CS308 Compiler Theory 27

 A Translation Scheme Example
• A simple translation scheme that converts infix expressions to the
corresponding
di postfixfi expressions.
i

E→TR
R → + T { print(“+”) } R1
R→ε
T → id { print(id.name) }

a+b+c Î ab+c+

infix expression postfix expression

CS308 Compiler Theory 28

 A Translation Scheme Example (cont.)
E

T R

id {print(“a”)} + T {print(“+”)} R

id {print(“b”)} + T {print(“+”)} R

id {print(“c”)} ε

The depth first traversal of the parse tree (executing the semantic actions in that order)
will produce the postfix representation of the infix expression.
CS308 Compiler Theory 29
 Inherited Attributes in Translation Schemes
• If a translation scheme has to contain both synthesized and inherited
attrib tes wee have
attributes, ha e to observe
obser e the following
follo ing rules:
r les:
1. An inherited attribute of a symbol on the right side of a production
must be computed in a semantic action before that symbol.
2. A semantic action must not refer to a synthesized attribute of a
symbol to the right of that semantic action.
3. A synthesized attribute for the non-terminal on the left can only be
computed after all attributes it references have been computed (we
normally put this semantic action at the end of the right side of the
production).
• With a L-attributed
L attributed syntax-directed
syntax directed definition
definition, it is always possible
to construct a corresponding translation scheme which satisfies
these three conditions (This may not be possible for a general
syntax-directed translation).
CS308 Compiler Theory 30
 Top-Down Translation
• We will look at the implementation of L-attributed definitions during
predictive
di i parsing.i
• Instead of the syntax-directed translations, we will work with
t
translation
l ti schemes.
h
• We will see how to evaluate inherited attributes (in L-attributed
definitions) during recursive predictive parsing.
parsing
• We will also look at what happens to attributes during the left-recursion
elimination in the left
left-recursive
recursive grammars
grammars.

CS308 Compiler Theory 31

 A Translation Scheme with Inherited Attributes
D → T id { addtype(id.entry,T.type), L.in = T.type } L
T → int { T.type = integer }
T → real { T.type = real }
L → id { addtype(id.entry,L.in), L1.in = L.in } L1
L→ε

• This is a translation scheme for an L-attributed definitions.

CS308 Compiler Theory 32

 Predictive Parsing (of Inherited Attributes)
procedure D() {
int Ttype,Lin,identry;
yp , , y;
call T(&Ttype); consume(id,&identry);
addtype(identry,Ttype); Lin=Ttype;
call L(Lin); a synthesized attribute (an output parameter)
}
procedure T(int *Ttype) {
if (currtoken is int) { consume(int); *Ttype=TYPEINT; }
else if (currtoken is real) { consume(real); *Ttype=TYPEREAL; }
else { error(“unexpected type”); } an inherited attribute (an input parameter)
}
procedure L(int Lin) {
if (currtoken is id) { int L1in,identry; consume(id,&identry);
addtype(identry,Lin); L1in=Lin; call L(L1in); }
else if (currtoken is endmarker) { }
else { error(“unexpected token”); }
}
CS308 Compiler Theory 33
Eliminating Left Recursion from Translation Scheme
• A translation scheme with a left recursive grammar.

E → E1 + T { E.val = E1.val + T.val }

E → E1 - T { E.val
E l = E1.vall - T.val
T l}
E→T { E.val = T.val }
T → T1 * F { T.val
T val = T1.val
val * F.val
F val }
T→F { T.val = F.val }
F → ( E ) { F.val
F val = E.val
E val }
F → digit { F.val = digit.lexval }

• When we eliminate the left recursion from the grammar (to get a
suitable grammar for the top-down parsing) we also have to change
semantic
i actions
i
CS308 Compiler Theory 34
 Eliminating Left Recursion (cont.)
inherited attribute synthesized attribute

E → T { A.in=T.val } A { E.val=A.syn }
A → + T { A1.in=A.in+T.val } A1 { A.syn = A1.syn}
A → - T { A1.in=A.in-T.val } A1 { A.syn = A1.syn}
A → ε { A.syn = A.in }
T → F { B.in=F.val } B { T.val=B.syn }
B → * F { B1.in=B.in*F.val } B1 { B.syn = B1.syn}
B → ε { B.syn = B.in }
F → ( E ) { F.val = E.val }
F → digit
g { F.val = digit.lexval
g }

CS308 Compiler Theory 35

 Eliminating Left Recursion (in general)
A → A1 Y { A.a = g(A1.a,Y.y) } a left recursive grammar with
A → X { A.a=f(X.x) } synthesized attributes (a,y,x).

⇓ eliminate left recursion

inherited attribute of the new non-terminal
synthesized attribute of the new non-terminal

A → X { R.in=f(X.x) } R { A.a=R.syn }
R → Y { R1.in=g(R.in,Y.y) } R1 { R.syn = R1.syn}
R → ε { R.syn
y = R.in }

CS308 Compiler Theory 36

 Evaluating attributes
A parse tree of left recursive grammar

A Y A.a=g(f(X.x),Y.y)
parse tree of non-left-recursive grammar
X X.x=f(X.x) A

X R.in=f(X.x) R A.a=g(f(X.x,Y.y)

Y R1.in=g(f(X.x),Y.y) R1 R.syn=g(f(X.x),Y.y)

ε R1.syn=g(f(X.x),Y.y)

CS308 Compiler Theory 37

Translation Scheme - Intermediate Code Generation
E → T { A.in=T.loc } A { E.loc=A.loc }
A → + T { A1.in=newtemp(); emit(add,A.in,T.loc,A1.in) }
A1 { A.loc = A1.loc}
A → ε { A.loc = A.in }
T → F { B.in=F.loc } B { T.loc=B.loc }
B → * F { B1.in=newtemp(); emit(mult,B.in,F.loc,B1.in) }
B1 { B.loc = B1.loc}
B → ε { B.loc = B.in }
F → ( E ) { F.loc = E.loc }
F → id { F.loc = id.name }

CS308 Compiler Theory 38

 Predictive Parsing – Intermediate Code Generation
procedure E(char **Eloc) {
char *Ain
Ain, *Tloc
Tloc, *Aloc;
Aloc;
call T(&Tloc); Ain=Tloc;
call A(Ain,&Aloc); *Eloc=Aloc;
}
procedure A(char *Ain, char **Aloc) {
if (currtok is +) {
char *A1in
*A1in, *Tloc
*Tloc, *A1loc;
consume(+); call T(&Tloc); A1in=newtemp(); emit(“add”,Ain,Tloc,A1in);
call A(A1in,&A1loc); *Aloc=A1loc;
}
else { *Aloc = Ain }
}

CS308 Compiler Theory 39

 Predictive Parsing (cont.)
procedure T(char **Tloc) {
char *Bin
Bin, *Floc
Floc, *Bloc;
Bloc;
call F(&Floc); Bin=Floc;
call B(Bin,&Bloc); *Tloc=Bloc;
}
procedure B(char *Bin, char **Bloc) {
if (currtok is *) {
char *B1in
*B1in, *Floc
*Floc, *B1loc;
consume(+); call F(&Floc); B1in=newtemp(); emit(“mult”,Bin,Floc,B1in);
call B(B1in,&B1loc); Bloc=B1loc;
}
else { *Bloc = Bin }
}
procedure
d F(
F(char
h **Fl
**Floc)) {
if (currtok is “(“) { char *Eloc; consume(“(“); call E(&Eloc); consume(“)”); *Floc=Eloc }
else { char *idname; consume(id,&idname); *Floc=idname }
}

CS308 Compiler Theory 40

 Bottom-Up Evaluation of Inherited Attributes
• Using a top-down translation scheme, we can implement any
L-attributed
ib d definition
d fi i i based
b d on a LL(1) ( ) grammar.
• Using a bottom-up translation scheme, we can also implement any
L tt ib t d definition
L-attributed d fi iti based
b d on a LL(1) grammar (each( h LL(1) grammar
is also an LR(1) grammar).
• In addition to the L-attributed
L attributed definitions based on LL(1) grammars,
grammars
we can implement some of L-attributed definitions based on LR(1)
ggrammars (not
( all of them)) using
g the bottom-upp translation scheme.

CS308 Compiler Theory 41

 Removing Embedding Semantic Actions
• In bottom-up evaluation scheme, the semantic actions are evaluated
d ring the reductions.
during red ctions
• During the bottom-up evaluation of S-attributed definitions, we have a
parallel stack to hold synthesized attributes.
• Problem: where are we going to hold inherited attributes?
• A Solution:
– We will convert our grammar to an equivalent grammar to guarantee to the
followings.
– All embedding semantic actions in our translation scheme will be moved into the
end of the production rules.
– All inherited attributes will be copied into the synthesized attributes (most of the
time synthesized attributes of new non-terminals).
non terminals)
– Thus we will be evaluate all semantic actions during reductions, and we find a
place to store an inherited attribute.

CS308 Compiler Theory 42

 Removing Embedding Semantic Actions
• To transform our translation scheme into an equivalent translation
scheme:
h
1. Remove an embedding semantic action Si, put new a non-terminal Mi
i t d off that
instead th t semantic
ti action.
ti
2. Put that semantic action Si into the end of a new production rule Mi→ε
for that non-terminal
non terminal Mi.
3. That semantic action Si will be evaluated when this new production
rule is reduced.
reduced
4. The evaluation order of the semantic rules are not changed by this
transformation.

CS308 Compiler Theory 43

 Removing Embedding Semantic Actions
A→ {S1} X1 {S2} X2 ... {Sn} Xn

⇓ remove embeddingg semantic actions

A→ M1 X1 M2 X2 ... Mn Xn
M1→ε {S1}
M2→ε {S2}
.
.
Mn→ε {Sn}

CS308 Compiler Theory 44

 Removing Embedding Semantic Actions
E→TR
R → + T { print(“+”)
i ( ) } R1
R→ε
T → id { print(id.name)
i t(id )}

⇓ remove embedding
b ddi semantic
i actions
i

E→TR
R → + T M R1
R→ε
T → id { print(id.name) }
M → ε { print(
print(“+”)
+ )}
CS308 Compiler Theory 45
 Translation with Inherited Attributes
• Let us assume that every non-terminal A has an inherited attribute A.i, and every
symbol X has a synthesized attribute X.s
X s in our grammar.
grammar
• For every production rule A→ X1 X2 ... Xn ,
– introduce new marker non-terminals M1,M2,...,Mn and
– replace this production rule with A→ M1 X1 M2 X2 ... Mn Xn
– the synthesized attribute of Xi will be not changed.
– the inherited attribute of Xi will be copied into the synthesized attribute of Mi by the new semantic
action added at the end of the new pproduction rule Mi→ε.
– Now, the inherited attribute of Xi can be found in the synthesized attribute of Mi (which is immediately
available in the stack.

A → {B.i=f1(...)} B {C.i=f2(...)} C {A.s= f3(...)}

⇓
A → {M1.i=f
i f1(...)}
( )} M1 {B.i=M
{B i M1.s}} B {M2.i=f
i f2(...)}
( )} M2 {C.i=M
{C i M2.s}} C {A.s=
{A f3(...)}
( )}
M1→ε {M1.s=M1.i}
M2→ε {{M2.s=M2.i}}

CS308 Compiler Theory 46

 Translation with Inherited Attributes
S → {A.i=1} A {S.s=k(A.i,A.s)}
A → {B.i=f(A.i)}
{B i f(A i)} B {C.i=g(A.i,B.i,B.s)}
{C i g(A i B i B s)} C {A.s=
{A s h(A.i,B.i,B.s,C.i,C.s)}
h(A i B i B s C i C s)}
B → b {B.s=m(B.i,b.s)}
C → c {C.s=n(C.i,c.s)}

S → {M1.i=1} M1 {A.i=M1.s} A {S.s=k(M1.s,A.s)}

A → {M2.ii=f(A
f(A.i)}
i)} M2 {B.i
{B i=M
M2.s}
s} B
{M3.i=g(A.i,M2.s,B.s)} M3 {C.i=M3.s} C {A.s= h(A.i, M2.s,B.s, M3.s,C.s)}
B → b {B.s=m(B.i,b.s)}
C → c {C.s=n(C.i,c.s)}
M1→ε {M1.s=M1.i}
M2→ε {{M2.s=M2.i}}
M3→ε {M3.s=M3.i}

CS308 Compiler Theory 47

 Actual Translation Scheme
S → {M1.i=1} M1 {A.i=M1.s} A {S.s=k(M1.s,A.s)}
A → {{M2.i=f(A.i)}
( )} M2 {{B.i=M2.s}} B {M
{ 3.i=g(A.i,M
g( 2.s,B.s)}
)} M3 {{C.i=M3.s}} C {A.s=
{ h(A.i,
( M2.s,B.s, M3.s,C.s)}
)}
B → b {B.s=m(B.i,b.s)}
C → c {C.s=n(C.i,c.s)}
M1→ε {{M1.s= M1.i}}
M2→ε {M2.s=M2.i}
M3→ε {M3.s=M3.i}

S → M1 A { s[ntop]=k(s[top-1],s[top]) }
M1→ ε { s[ntop]=1 }
A → M2 B M3 C { s[ntop]=h(s[top-4],s[top-3],s[top-2],s[top-1],s[top]) }
M2→ ε { s[ntop]=f(s[top]) }
M3→ ε { s[ntop]=g(s[top-2],s[top-1],s[top])}
B→b { s[ntop]=m(s[top-1],s[top]) }
C→c { s[ntop]=n(s[top-1]
s[ntop] n(s[top-1],s[top])
s[top]) }

CS308 Compiler Theory 48

 Evaluation of Attributes
S
S k(1 h( ))
S.s=k(1,h(..))
A.i=1
A
A.s=h(1,f(1),m(..),g(..),n(..))

B.i=f(1) C.i=g(1,f(1),m(..))
B C
B
B.s=m(f(1),b.s)
(f(1) b ) C
C.s=n(g(..),c.s)
( ( ) )

b c

CS308 Compiler Theory 49

 Evaluation of Attributes
stack input s-attribute stack
bc$
M1 bc$ 1
M1 M2 bc$ 1 f(1)
M1 M2 b c$ 1 f(1) b.s
M1 M2 B c$ 1 f(1) m(f(1),b.s)
M1 M2 B M3 c$ 1 f(1) m(f(1),b.s) g(1,f(1),m(f(1),b.s))
M1 M2 B M3 c $ 1 f(1) m(f(1),b.s) g(1,f(1),m(f(1),b.s)) c.s
M1 M2 B M3 C $ 1 f(1) m(f(1),b.s) g(1,f(1),m(f(1),b.s)) n(g(..),c.s)
M1 A $ 1 h(f(1),m(..),g(..),n(..))
S $ k(1,h(..))
( ( ))

CS308 Compiler Theory 50

 Problems
• All L-attributed definitions based on LR grammars cannot be evaluated
d i bottom-up
during b parsing.
i

S → { L.i=0 } L Î this translations scheme cannot be implemented

L → { L1.i=L.i+1 } L1 1 during the bottom-up parsing
L → ε { print(L.i)
i t(L i) }

S → M1 L
L → M2 L1 1 Î But since L → ε will be reduced first by the bottom-up
L → ε { print(s[top]) } parser, the translator cannot know the number of 1s.
M1 → ε { s[ntop]=0 }
M2 → ε { s[ntop]=s[top]+1 }

CS308 Compiler Theory 51

 Problems
• The modified grammar cannot be LR grammar anymore.

L→Lb L→MLb
L→a Î L→a NOT
O LR-grammar
M→ε

.
S’ → L,, $
L → . M L b, $
L → . a,, $
M → .,a Î shift/reduce conflict

CS308 Compiler Theory 52