1. Topic 5 -Semantic Analysis Dr. William A. Maniatty Assistant Prof. Dept. of Computer Science University At Albany CSI 511 Programming Languages and Systems Concepts Fall 2002 Monday Wednesday 2:30-3:50 LI 99

2. Introduction to Semantic Analysis  Semantics are what a program means  Decorating the parse tree/syntax tree is done to generate code and analyze semantics.  Actions are inserted into the parser to generate the semantic analysis when language constructs are recognized.  Analysis means  Determining correct behavior  Detecting Dangerous or Nonsensical Behavior

3. When are Semantics Analyzed?  Semantic analysis done at compile time and run time  Can be done at most binding times.  Compilers split into front end/back end  Back end does semantic analysis  Front end does syntax analysis

4. Some notes on correctness  Semantic errors are hard to catch at compile time  Late binding makes static analysis hard  Correct programs can be derived  But this is hard and typically done for short heavily used code  In practice, combine static analysis and run time checking to help the programmer.

5. So, Why does my software crash?  Engineers know how to make working machines, why does software crash?  Software is discrete.  Failure not gradual or but discontinuous.  Analysis/understanding is hard  Bad Tools, Bad Techniques or Bad Paradigm?  Like doing calculus with roman numerals  Cost and performance trade offs  Last to market loses, Slow performance loses.

6. The Role of Testing and Verification  Verification - Derive correct solution  Useful but hard, expensive and not feasible for large pieces of software.  Testing - Checks for the presence of errors.  But cannot rule out errors.  Cheaper, and practical.  Catching errors late increases repair costs.

7. Assertions, Invariants, Pre/Post Conditions  Hardware provides some runtime checks  Languages can support testing:  Assertion - A condition which must be true at a particular point during execution.  Invariant -A condition which must hold true at all "clean points" of execution  Precondition - True before a statement  Postcondition - Ture after a statement

8. Attribute Grammars 1  Recall that context free grammars specify programming language syntax.  An Attribute grammar (AG) extends the CFG to specify semantics of the language.  Each nonterminal is associated with a set of attributes (semantic information)  Each production has a set of semantic rules.  Terminals can supply needed information.

9. Attribute Grammars 2  Semantic Rules are either:  Copy rules -Copy the RHS Attribute to LHS  Semantic Functions -Perform some function on the RHS attributes.  The Semantic Rules are simple  Refer to information available in the RHS of the production.  Avoid using non-local information

10. Attribute Grammars 3  Closely related to:  Denotational Semantics -Focus on machine independent details.  Axiomatic Semantics - Focuses on verification/theorem proving.

11. Attribute Grammars An Example

12. Attribute Tree Construction  CFGs and Attribute Grammars do not specify:  Shape of the parse/attribute tree  Order of parse/attribute tree construction  Attribute Trees can be constructed:  On the fly - At the same time as parse tree  After the parse tree is built (in another pass)

13. Attribute Trees  Attribute Trees are annotated parse trees  Attributes flow between nodes  Values initialized by leaf nodes  Synthesized Attributes are computed only in productions where the nonterminal appears on the RHS  S-Attributed grammars synthesize all their attributes.  Scanner gives initial attributes for tokens

14. Attribute Flow  Attribute Trees are annotated parse trees  Attribute flow is the pattern of information movement in the attribute grammar tree.  Synthesized Attributes are computed in productions with the nonterminal on the LHS  S-Attributed grammars synthesize all their attributes.  Inherited attributes are calculated when a symbol is on the RHS of a production.

15. Attribute Flow LR Example  LR Parsers have  Rightmost Trees  Bottom-Up Construction  Attributes Flow Along Parse Tree Edges.  In Bottom-Up Direction  Can Augment Parser Stack  E.g. AG for (3 + 1) * 2

16. Attribute Flow LR Example  Attributes initialized by scanner.  Transitive closure of copied pointers makes attributes available when evaluated.

17. Attribute Flow in LL Grammars  Notice that some productions have multiple rules.  TT and FT use an extra "subtotal" attribute.  If a symbol is on LHS and RHS add a subscript.

18. Attribute Flow in LL Grammars  Minor errata, the RHS in expression 3: should be  TT 1 } - T TT 2

19. Attribute Flow in LL Grammars  LL Grammars need to work with  Leftmost parse tree derivations  Top to bottom  L-Attributed grammars do as follows:  Each LHS symbol's attributes depend on  The symbol's own attributes  Attributes of a symbol on the RHS  Each inherited attribute depends only on inherited attributes of the LHS grammars.

20. Attribute Flow in LL Grammars

22. So Why are Attribute Flows Important?  A translation scheme is an algorithm that invokes the attributes of a parse tree in an order consistent with its attribute flow.  This is how compilers generate code!  One Pass compilers can evaluate attributes during parse tree construction using a stack.  LR Parsers can mirror or augment the parse stack  Since The Attribute Flow Mimics the parse tree  LL Parsers need a separate attribute stack.

23. Some Notation  An AG is well-defined if every parse tree has a unique set of attributes.  An AG is noncircular if no attribute ever depends (transitively) on itself.

24. Action Routines  Action routines realize the AG:  What Semantic Rule to apply  When (during what phase of parsing)  Can be after parsing the entire RHS (typical)  Can be in the middle of parsing the RHS  Sometimes convenient  Does LL differ from LR?  Yes, LL can evaluate any time, with LR you may get conflicts (when to shift/reduce?)

25. An LL Action Routine Example  Given the same LL AG as earlier  Insert action routines  Predictive nature of LL allows actions at arbitrary times

26. YACC and Bison Handling of Attributes 1  YACC and BISON are LALR(1) parsers  Attributes are managed with a stack  Augment the parse stack  To access attributes in a production  The attributes on the LHS is denoted $$  The symbol's attributes on the RHS are denoted $1, $2,..., $n where $i is the ith term from the left

27. YACC and Bison Semantic Values  Symbol attributes are pushed on the stack  Want to change the stack's element type.  To select a stack element type:  For single type stacks, define YYTYPE:  #define YYTYPE typename // A macro  For multi-type stacks, use %union  Each field in the union becomes is a type  Access them using say $ 1

28. YACC and Bison Semantic Values  Attribute initialization:  Synthesized Attributes are assigned, using a statement like:  $$ = f($1, $2,..., $n); /* n = |RHS|, f is a function */  Sometimes Inherited Attributes are useful  e.g. A grammar has productions:  Decl } Type Id_List; and, Id_List } Id, Id_List | Id;  So need to set an Id's type need a statement like  $1.type = $$.type; $2.type = $$.type

29. YACC and Bison Semantic Values  Symbol attributes are pushed on the stack  Want to change the stack's element type.  To select a stack element type:  For single type stacks, define YYTYPE:  #define YYTYPE typename // A macro  For multi-type stacks, use %union  Each field in the union becomes is a type