Chapter 5. Syntax-Directed Translation

1. Chapter 5.Syntax-Directed Translation

2. Fig. 5.2. Syntax-directed definition of a simple desk calculator

3. Fig. 5.3. Annotated parse tree for 3*5+4n.

4. Fig. 5.4. Syntax-directed definition with inherited attribute L.in.

5. Fig. 5.5. Parse tree with inherited attribute in at each node labeled L.

6. Fig. 5.6.E.val is synthesized from E1.val and E2.val

7. Fig. 5.7. Dependency graph for parse tree of Fig. 5.5

8. Fig. 5.9. Syntax-directed definition for constructing a syntax tree for an expression

9. Fig. 5.10. Construction of a syntax-tree for a-4+c

10. Fig. 5.11. Dag for the expression a+a*(b-c)+(b-c)*d.

11. Fig. 5.12. Instructions for constructing the dag of Fig. 5.11 (1) p1:= mkleaf ( id, a ) (2) p2:= mkleaf ( id, a ) (3) p3:= mkleaf ( id, b ) (4) p4:= mkleaf ( id, c ) (5) p5:= mknode ( ‘-’, p3, p4) (6) p6:= mknode ( ‘*’, p2, p5) (7) p7:= mknode ( ‘+’, p1, p6) (8) p8:= mkleaf ( id, b ) (9) p9:= mkleaf ( id, c ) (10) p10:= mknode ( ‘-’, p8, p9) (11) p11:= mkleaf ( id, d ) (12) p12:= mknode ( ‘*’, p10, p11) (13) p13:= mknode ( ‘+’, p7, p12)

12. Fig. 5.15. Parser stack with a field for synthesized attributes

13. Fig. 5.16. Implementation of a desk calculator with an LR parser.

14. L-Attributed Definitions A syntax-directed definition is L-attribute if each inherited attribute of Xj, 1≤j≤n, on the right side of A→ X1X2 · · · Xn , depends only on 1. the attributes of the symbols X1 ,X2 ,· · · ,Xj-1 to the left of Xj in the production and • the inherited attributes of A. Note that every S-attributes definition is L-attributed, because the restrictions (1) and (2) apply only to inherited attributes

15. Example 5.17. The type of an identifier can be passed by copy rules using inherited attributes as shown in Fig. 5.32 (adapted from Fig. 5.7). We shall first examine the moves made by a bottom-up parser on the inputreal p, q, r then we show how the value of attirbute T.type can be accessed when the productions for L are applied. The translation scheme we wish to implement is D  T L {L.in := T.type } T int {T.type := integer} T real {T.type := real} L {L1.in := L.in } L1 , id{addtype ( id.entry , L.in )} L  id {addtype ( id.entry , L.in )}

16. Fig.5.32. At each node for L, L.in = T.type. If we ignore the actions in the above translation scheme, the sequence of moves made by the parser on the input of Fig. 5.32. is as in Fig. 5.33. For clarity, we show the corresponding grammar symbol instead of a stack state and the actual identifier instead of the token id.

17. Fig. 5.33.Whenever a right side for L is reduced, T is just below the right side.

18. Fig. 5.34. The value of T.type is used in place of L.in

19. Example 5.18. As an instance where we cannot predict the position, consider the following translation scheme: (5.6) C inherits the synthesized attribute A.s by a copy rule. Note that there may or may not be a B between A and C in the stack. When reduction by C → c is performed, the value of C.i is either in val [top−1]or in val [top−2], but it is not clear which case applies.

20. Fig. 5.35. Copying an attribute value through a marker M. є (a) original production (b) modified dependencies

21. Fig. 8.7. Semantic rules generating code for a while statement ProductionSemantic Rules S -> whileEdoS1S.begin := newlabel ; S.after := newlabel ; S.code := gen( S.begin ‘ :’) || E.code || gen( ‘ if ’ E.place ‘ = ‘ ‘ 0 ’ ‘ goto’ S.after ) || S1.code || gen(‘ goto’ S.begin ) || gen( S.after ‘ : ‘ )