Lesson 11

1. Lesson 11 CDT301 – CompilerTheory, Spring 2011 Teacher: Linus Källberg

2. Outline • Syntax-directed specifications of language semantics • Syntax-directed definitions • Syntax-directed translation schemes • Semantic analysis • Focus on type analysis

3. Syntax-directed specifications of language semantics

4. Overview of syntax-directed specifications of semantics • Semantics can be expressed by: • Attaching attributes to grammar symbols • Specifying how to compute those attributes: • By adding semantic rules, we get a syntax-directed definition (SDD) • By adding semantic actions, we get a syntax-directed translation scheme (SDT)

5. Examples of attributes:values of evaluated subtrees E E.val = 7 Grammar: E → E + T E → T T → num E + E.val = 3 T num T.val = 3 T num.val = 4 String: 3 + 4 num num.val = 3

6. Examples of attributes:(line, column) in source file E.coord = (1,1) to (1,6) E Grammar: E → E + T E → T T → num E.coord =(1,1) to (1,2) E + T +.coord = (1,3) to (1,4) T.coord =(1,1) to (1,2) num T num.coord =(1,5) to (1,6) String: 3❏+❏4 num num.coord =(1,1) to (1,2)

7. Examples of attributes:data types E E.type = int Grammar: E → E + T E → T T → num E + E.type = int T num T.type = int T num.type = int String: 3 + 4 num num.type = int

8. SDDs vs. SDTs SDDs SDTs Explicitly specify an evaluation order for the semantic actions The actions may appear anywhere in the production bodies The semantic actions may be arbitrary code fragments Mostly useful for implementation • Do not specify any evaluation order for the semantic rules • The rules appear at the end of the production bodies • The semantic rules may only have controlled side effects • Mostly useful for specification

9. Syntax-directed definitions • SDD of values of evaluated subtrees: ProductionRules E → E1 + T E.val = E1.val + T.val E → T E.val = T.val T → numT.val = num.val • Each node has an attribute val holding the value of its evaluated subtree

10. Types of attributes • An attribute at a parse tree node N may be of two kinds: • Synthesized • Computed in terms of attributes at the children of N and/or other attributes at N • Inherited • Assigned to N at the parent of N

11. Annotated parse tree for “3 + 4” E.val = 7 E.val = 3 + T.val = 4 T.val = 3 num.val = 4 num.val = 3

12. Inherited attributes • After eliminating left recursion from the previous grammar: ProductionRules E → T E' E'.inh = T.val E.val = E'.syn E' → + T E'1 E'1.inh = E'.inh + T.val E'.syn = E'1.syn E' → ε E'.syn = E'.inh T → numT.val = num.val

13. Annotated parse tree for “3 + 4” E.val = 7 E'.inh = 3 E'.syn = 7 T.val = 3 E'.inh = 7 E'.syn = 7 T.val = 4 num.val = 3 + num.val = 4 ε

14. L Classes of SDDs S • S-attributed SDDs: • Only synthesized attributes • L-attributed SDDs: • Inherited attributes depend on attributes of symbols to the left in the production (including the head) • Attributes at a node N can also depend on other attributes at N, if it does not introduce dependency cycles • In the first lab, you used an L-attributed SDD • In the third lab, you will use an S-attributed SDD

15. Example of non-L-attributed SDD ProductionSemanticrules A → B C A.syn = B.syn; B.inh = f(C.syn, A.syn)

16. Example SDD • Grammar for mathematical functions: E → E + E E → E * E E → num | x | ( E ) • Goal: specify an SDD for the translation of an expression into its derivative (as a string), recalling the rules: x’ = 1 n’ = 0 (f * g)’ = f’ * g + f * g’ (f + g)’ = f’ + g’

17. Example SDD ProductionRulesE → E1 + E2 E.expr = E1.expr || ”+” || E2.expr E.der = ”(” || E1.der || ”+” || E2.der || ”)” E → E1 * E2 E.expr = E1.expr || ”*” || E2. expr E.der = ”(” || E1.der || ”*” || E2. expr || ”+” || E1.expr || ”*” || E2.der || ”)” E → x E.expr = ”x” E.der = ”1” E → num E.expr = num.val E.der = ”0” E → ( E1 ) E.expr = ”(” || E1.expr || ”)” E.der = E1.der Where || is the string concatenation operator

18. Exercise (1) Draw the parse tree for the string 2*(x + x) Then decorate it using the SDD on the previous slide.

19. Exercise (2) Complete the following SDD of values of evaluated subtrees. ProductionRules E → T E‘ E'.inh = T.val E.val = E'.synE' → + T E'1 E'1.inh = E'.inh + T.valE'.syn = E'1.synE' → εE'.syn = E'.inh T → F T' ? T' → * F T'1 ? T' → ε ? F → numF.val = num.valF → ( E ) ?

20. Semantic analysis

21. Semantic analysis • Why? • Not all errors are lexical or syntactical • Needed to generate correct code • When? • Can be done during parsing (semantic actions) • Easier in separate passes on some intermediate program representation

22. Semantic analysis –name analysis • Examples of name analyses from trac42: • Is a referenced variable declared? • Is a variable uniquely declared in the scope? • Is a called function declared/defined? voidmy_func(void){int x = y + 23 * my_fnuc();char x = ‘x’;}

23. Semantic analysis –type analysis • Examples of type analyses from trac42: • Is an operator applied to operands of the right types? • Is a function called with the right number of arguments? • Are the function arguments of the right types? intmy_func(intarg){int x = arg * “blablabla”;int y = my_func(23, 78);returnmy_func(37.8);}

24. More examples ofsemantic analyses • Is a “break” statement enclosed in a loop or a switch? (C, C++, C#, Java…) • From ADA: The beginning and end of blocks should be tagged with the same name

25. Static vs. dynamic checks • Static checks are done during compilation • Static type checks requires type specifications by the programmer or type inference by the compiler • Dynamic checks are done during runtime • Dynamic type checks require type information to be carried with data objects. Examples: • A ” type” member in structs • Vpointers and vtables in OO languages • Trac42 needs only static checks

26. Type analysis • Type information is gathered from: • Declarations of variables and functions char str[256]; int some_func(float arg); • Format of constants x = 15.7f; c = ’a’; z = 98ul; • A type system specifies how to assign type attributes to program parts • More on this in the next lecture

27. What is a type? • Specification of: • The size needed to store a data object • How to interpret the stored data • Examples: • Unsigned short: needs 16 bits and is interpreted as a number from 0 to 65535 • Signed short: needs 16 bits and is interpreted as a number from -32768 to 32767

28. Using types for code generation unsigned x;unsigned y = 24;unsigned z = 6;x = y / z; … divl -8(%ebp) … int x;int y = 24;int z = 6;x = y / z; … idivl -8(%ebp) …

29. Type conversions • Changes the type of a data object • Explicit: int a = 12; float b = (float) a; void* p_v = (void*) &a; int* p_i = (int*) p_v; • Implicit (coercions): inferred by the compiler: char a = 12; int b = a; float x = 17; • Trac42 does not have type conversions

30. Representing types • Type expressions: • Basic types, e.g., int, char, float • void – No value • error – Erroneous type • Type names • Type constructors. Examples: • int* p; pointer(int) • int a[27]; array(27, int); • int f(char a, float b); char × float → int

31. Representing types –type constructors • pointer(T) • Pointer to an object of type T • array(I, T) • Array with I nr of elements of type T • T1 × T2 • Product of types T1 and T2

32. Representing types –type constructors • Records. Similar to products, but includes the member name. • Example:struct A { int a; char b; }; record((a x integer) x (b x char)) • T1 → T2 • Function taking the type T1 as argument and returning T2 • T1 is often a product type

33. Tree representation oftype expressions • Example: • int* my_func(char a, char b); • Type of my_func: char × char → pointer(int) → pointer × char char int

34. Exercise (3) Write the type expression and draw it as a tree for the function char** your_func(int a, char* b, float c);

35. Conclusion • SDDs and SDTs are two similar ways to attach semantics to a grammar • Attributes on grammar symbols can be synthesized or inherited • Data types are needed to guard against errors and to generate correct code • Types can be represented as type expressions

36. Next time • More type analysis