1 / 37

# Syntax Analysis

Syntax Analysis. Mooly Sagiv html://www.math.tau.ac.il/~msagiv/courses/wcc03.html Textbook:Modern Compiler Design Chapter 2.2 (Partial) Hashlama 11:00-14:00 Melamed. A motivating example. Create a desk calculator Challenges Non trivial syntax Recursive expressions (semantics)

Télécharger la présentation

## Syntax Analysis

E N D

### Presentation Transcript

1. Syntax Analysis Mooly Sagiv html://www.math.tau.ac.il/~msagiv/courses/wcc03.html Textbook:Modern Compiler Design Chapter 2.2 (Partial) Hashlama 11:00-14:00 Melamed

2. A motivating example • Create a desk calculator • Challenges • Non trivial syntax • Recursive expressions (semantics) • Operator precedence

3. Solution (lexical analysis) /* desk.l */ %% [0-9]+ { yylval = atoi(yytext); return NUM ;} “+” { return PLUS ;} “-” { return MINUS ;} “/” { return DIV ;} “*” { return MUL ;} “(“ { return LPAR ;} “)” { return RPAR ;} “//”.*[\n] ; /* comment */ [\t\n ] ; /* whitespace */ . { error (“illegal symbol”, yytext[0]); }

4. Solution (syntax analysis) /* desk.y */ %token NUM %left PLUS, MINUS %left MUL, DIV %token LPAR, RPAR %start P %% P : E {printf(“%d\n”, \$1) ;} ; E : NUM { \$\$ = \$1 ;} | LPAR e RPAR { \$\$ = \$2; } | e PLUS e { \$\$ = \$1 + \$3 ; } | e MINUS e { \$\$ = \$1 - \$3 ; } | e MUL e { \$\$ = \$1 * \$3; } | e DIV e {\$\$ = \$1 / \$3; } ; %% #include “lex.yy.c” flex desk.l bison desk.y cc y.tab.c –ll -ly

5. Solution (syntax analysis) a.out <input // input 7 + 5 * 3 22

6. Subjects • The task of syntax analysis • Automatic generation • Error handling • Context Free Grammars • Ambiguous Grammars • Top-Down vs. Bottom-Up parsing • Bottom-up Parsing

7. Basic Compiler Phases Source program (string) Front-End lexical analysis Tokens syntax analysis Abstract syntax tree semantic analysis Back-End Fin. Assembly

8. Syntax Analysis (Parsing) • input • Sequence of tokens • output • Abstract Syntax Tree • Report syntax errors • unbalanced parenthesizes • [Create “symbol-table” ] • [Create pretty-printed version of the program] • In some cases the tree need not be generated (one-pass compilers)

9. Handling Syntax Errors • Report and locate the error • Diagnose the error • Correct the error • Recover from the error in order to discover more errors • without reporting too many “strange” errors

10. Example a := a * ( b + c * d ;

11. The Valid Prefix Property • For every prefix tokens • t1,t2, …,tithat the parser identifies as legal: • there exists tokensti+1, ti+2, …, tnsuch thatt1, t2, …, tnis a syntactically valid program • If every token is considered as single character: • For every prefix word uthat the parser identifies as legal: • there exists w such that • u.w is a valid program

12. Error Diagnosis • Line number • may be far from the actual error • The current token • The expected tokens • Parser configuration

13. Error Recovery • Becomes less important in interactive environments • Example heuristics: • Search for a semi-column and ignore the statement • Try to “replace” tokens for common errors • Refrain from reporting 3 subsequent errors • Globally optimal solutions • For every input w, find a valid program w’ with a “minimal-distance” from w

14. Why use context free grammarsfor defining PL syntax? • Captures program structure (hierarchy) • Employ formal theory results • Automatically create “efficient” parsers

15. What is a grammar Derivations and Parsing Trees Ambiguous grammars Resolving ambiguity Context Free Grammar (Review)

16. Non-terminals Start non-terminal Terminals (tokens) Context Free Rules<Non-Terminal>  Symbol Symbol … Symbol Context Free Grammars

17. Example Context Free Grammar 1 S  S ; S 2 S  id := E 3 S print (L) 4 E id 5 E num 6 E  E + E 7 E (S, E) 8 L  E 9 L  L, E

18. Show that a sentence is in the grammar (valid program) Start with the start symbol Repeatedly replace one of the non-terminals by a right-hand side of a production Stop when the sentence contains terminals only Rightmost derivation Leftmost derivation Derivations

19. Example Derivations S S ; S 1 S  S ; S 2 S  id := E 3 S  print (L) 4 E  id 5 E  num 6 E  E + E 7 E  (S, E) 8 L  E 9 L  L, E S ; id := E id := E ; id := E id := num ; id := E id := num ; id := E + E id := num ; id := E + num id := num ; id :=num + num a 56 b 77 16

20. The trace of a derivation Every internal node is labeled by a non-terminal Each symbol is connected to the deriving non-terminal Parse Trees

21. Example Parse Tree S s S ; S s s ; S ; id := E id := E ; id := E id := E id := E id := num ; id := E id := E E + E id := num ; id := E + E id := num ; id := E + num num num num id := num ; id :=num + num

22. Two leftmost derivations Two rightmost derivations Two parse trees Ambiguous Grammars

23. A Grammar for Arithmetic Expressions 1 E  E + E 2 E  E * E 3 E  id 4 E  (E)

24. Drawbacks of Ambiguous Grammars • Ambiguous semantics • Parsing complexity • May affect other phases

25. Non Ambiguous Grammarfor Arithmetic Expressions Ambiguous grammar • E  E + T • E  T • T  T * F • T  F • 5 F  id • 6 F  (E) 1 E  E + E 2 E  E * E 3 E  id 4 E  (E)

26. Non Ambiguous Grammarsfor Arithmetic Expressions Ambiguous grammar • E  E + T • E  T • T  T * F • T  F • 5 F  id • 6 F  (E) • E  E * T • E  T • T  F + T • T  F • 5 F  id • 6 F  (E) 1 E  E + E 2 E  E * E 3 E  id 4 E  (E)

27. Pushdown automata Deterministic Report an error as soon as the input is not a prefix of a valid program Not usable for all context free grammars context free grammar parser tokens Efficient Parsers bison “Ambiguity errors” parse tree

28. Designing a parser language design context-free grammar design Bison parser (c program)

29. Top-Down (Predictive Parsing) LL Construct parse tree in a top-down matter Find the leftmost derivation For every non-terminal and token predict the next production Preorder tree traversal Bottom-Up LR Construct parse tree in a bottom-up manner Find the rightmost derivation in a reverse order For every potential right hand side and token decide when a production is found Postorder tree traversal Kinds of Parsers

30. Top-Down Parsing

31. Bottom-Up Parsing

32. Example Grammar for Predictive LL Parsing expression  digit | ‘(‘ expression operator expression ‘)’ operator  ‘+’ | ‘*’ digit  ‘0’ | ‘1’ | ‘2’ | ‘3’ | ‘4’ | ‘5’ | ‘6’ | ‘7’ | ‘8’ | ‘9’

33. Parsing Expressions • Try every alternative production • For P  A1 A2 … An | B1 B2 … Bm • If A1 succeeds • Call A2 • If A2 succeeds • Call A3 • If A2 fails report an error • Otherwise try B1 • Recursive descent parsing • Can be applied for certain grammars • Generalization: LL1 parsing

34. Predictive Parser for Arithmetic Expressions • Grammar • C-code? • E  E + T • E  T • T  T * F • T  F • 5 F  id • 6 F  (E)

35. Summary • Context free grammars provide a natural way to define the syntax of programming languages • Ambiguity may be resolved • Predictive parsing is natural • Good error messages • Natural error recovery • But not expressive enough • But LR bottom-up parsing is more expressible

More Related