: Compiler Design

Size: px

Start display at page:

Download ": Compiler Design"

Abigail Flowers
5 years ago
Views:

1 : Compiler Design 3.4 Bo'om- up parsing Thomas R. Gross Computer Science Department ETH Zurich, Switzerland

2 Outline (How to generate parsing control table M of stack machine) (For bo'om- up parsing) (Simulate deriva<ons to find handles) Another example Boundary cases 4.0 SemanOc checking 2

3 PredicOve parsing There cannot be a conflict between shi\ing and reducing, e.g. ac<on(i j, t) : shiw and ac<on(i j, t) : reduce This is called a shi\- reduce conflict It must be clear which producoon to use when reducing ac<on(i j, t) : reduce X à α and ac<on(i j, t) : reduce Y à β This is called a reduce- reduce conflict 9

4 Bodom- up parsing in perspecove Items LR(0) items Did not use any info about context when construc<ng the items FOLLOW() entered the picture when we set up the parsing table M Parser: simple LR(1) parser 1 because one input symbol is used simple because we take the LR(0) items Known as SLR (or SLR(1)) parser Grammar said to be an SLR(1) grammar 10

5 SLR(1) grammars SLR(1) grammars are unambiguous Proof by construc<on SLR parsers don t work for many programming language constructs 11

6 Boundaries Consider this grammar G S! X x X y Y y Y x X! ε Y! ε Terminals: { x, y } Non- terminals: {S, X, Y } L(G) ={ xy, yx } Construct the parsing table Start with item set I 0 Need FIRST() and FOLLOW() Don t forget to add S! S 14

7 Is G SLR(1)? Item set I 0 : { [S à S], [S à X x X y] [S à Y y Y x] [X à ] [Y à ] } FOLLOW(X) = FOLLOW(Y) = {x, y} M[I 0, x ] = M[I 0, y ] : {reduce X! ε, reduce Y! ε } A reduce- reduce conflict Parser cannot decide which produc<on to use 16

8 More on G What would the top- down predicove parser of 3.3 do? G is unambiguous G is LL(1) 19

9 Boundaries Consider this grammar G S! L = R R L! * R Id R! L Terminals: { =, *, Id } Non- terminals: {S, L, R } Grammar models (part of) C- style assignments: * is the contents- of operator, = assignment R: r- value L: l- value 20

10 Boundaries Problem is construcoon of LR(0) items LR(0) does not consider context (Over)approximate by using FOLLOW(X) to decide when to reduce X à ε SoluOon: more accurate construcoon of item sets Introduce context informa<on into item Context: next input canonical LR parsing Canonical LR o\en referred to as LR 21

11 Canonical LR parsing Use LR(1) items Like LR(0) but with look- ahead LR(1) has look- ahead of 1 Larger look- aheads are possible General format: [A! α, t ] t T t is the look- ahead symbol Reduce with α on top of the stack only if the next input symbol is t [A à α β, t ] with β ε look- ahead has no effect Parsing table for M [ X, t] set to reduce A! α only for t if [A! α, t ] item set X Subset of FOLLOW(A) 22

12 LR parsing Same approach as explained for SLR parsing Troublesome news: We can construct grammars G n such that G n has n non- terminals 2n 2 n produc<ons and 2 n + n 2 + n states (sets of items) Even with large VM that s not good. 24

13 VariaOons Lookahead LR(1) LALR Reduced number of states About 2x number of states of LL(1) grammar for same language Very popular yacc and bison Space savings not that crucial anymore, LL is making a comeback 25

14 Grammar world 26

15 Parser generators Parsers are not constructed by hand GeneraOon of LR(0) items, LR(1) items can be automated Also genera<on of LL(1), LL(2), parsers Parser generator: takes grammar and constructs parser or reports shiw/reduce or reduce/reduce conflicts Time to rework the grammar or use other parser generator Popular parser generators Yacc Bison ANTLR JavaCUP ( Construc<on of Useful Parsers ) 27

16 Further topics Error handling Report meaningful informa<on in case w L(G) At least line number of suspected error Not syntax error Should the parser repair input? Efficiency missing semi- colon Grammar massaging LL(1) tends to require more work as common prefixes must be factored out Syntax analysis as you type ( on the fly ) 28

17 Context- free Efficient parsers exist for context- free languages Should we look at other language classes Context- sensi<ve Unrestricted grammars Grammar "! checking properoes 29

18 Compiler structure Parser builds parse tree Can be turned into abstract syntax tree (AST) Checks input for compliance with language spec Can be turned into abstract syntax tree (AST) Remove unnecessary detail Most details related to grammar symbols is not cri<cal From parse tree / AST to code generaoon We did this in Assignment 1 30

19 Error detecoon Parse tree construcoon Parser finds some kinds of errors but not all Some kinds of errors can be detected only at run<me Syntax errors Efficient parsing algorithms known for Type- 2 (context- free) grammars Not always desirable: find errors with parser Limita<ons of context- free grammars 32

20 A useful property: variables declared Consider a language like Java(Li) The spec requires that all variables used have been declared int x;! x = x + 1! 34

21 Useful property How could we express this property so that it can be checked by the parser? A parse tree is constructed only for those programs that maintain this property (variables declared before use) Can we find a language L 1 to model this property? Then we can think about a grammar G 1 such that L(G 1 ) = L 1 35

22 L 1 L 1 = { α c α α {a, b}* } Terminals: a, b, c Example words from L 1 : aacaa abcab aabacaaba.. Not in L 1 : ca acb How does L 1 relate to our problem? 36

23 void fct1() {! int x;! {! x = x + 1!! }! }! void fct2() {! int x;! {! x = y + 1!! }! }! Could use L 1 = { α c α d α {a, b}* } 38

24 L 1 L 1 allows us to model the following constraint Any variable that appears in the program/func;on/method has been declared previously c defines a separa<on between the body of a unit and the defini<on block Useful property to check before code generaoon Bad news: (Theorem) There exists no context- free grammar G such that L 1 = L(G) Proof: 41

25 A useful property: matching parameters Consider a language like Java(Li) The spec requires that for all methods/funcoons, the number of formal parameters (at the place of method definioon) matches the number of actual parameters (at the call site)! int fct (int a, float b, xref c) { }! x = fct(a, b, c)! 43

26 Useful property How could we express this property so that it can be checked by the parser? A parse tree is constructed only for those programs that maintain this property (actuals and formals match) Can we find a language L 2 to model this property? Then we can think about a grammar G 2 such that L(G 2 ) = L 2 44

27 L 2 L 2 = { a n b m c n d m } a, b, c, d: terminals Integers n, m 1 Example words from L 2 : aabccd aaabbcccdd abbbbcdddd Not in L 2 : aabcd Why would we care about L 2? 46

28 L 2 L 2 allows us to model the following constraint For all methods/func;ons, the number of formal parameters (at the place of method defini;on) matches the number of actual parameters (at the call site) Can be extended to deal with matching types Tricky if type conversions are an op<on Useful property to check before code generaoon Bad news: (Theorem) There exists no context- free grammar G such that L 2 = L(G) Proof: 48

29 Comments Context- free grammars cannot express all desirable constraints Switching to context- sensi<ve not produc<ve Use unrestricted grammar instead Use a program to perform addioonal checks Complete flexibility Recall: some checks must wait <ll run <me 49

30 More comments Note: Parsing also used in (natural) language processing No (complete) (context- free) grammar exists for English, German, Ambiguity part of reality May need to obtain (mul<ple, all) parse trees The food is here! vs The food is here? InteresOng topic but not part of this class 50

31 : Compiler Design 4.0 Seman*c analysis Thomas R. Gross Computer Science Department ETH Zurich, Switzerland

32 4.0 SemanDc analysis Idea: before proceeding to code generadon compiler checks program properdes Early feedback While source info s*ll available Avoid subsequent complica*ons Also the Dme to transform program done at the *me parse tree is transformed into abstract syntax tree Example transforma*ons: Add default parameters to method/func*on calls Type casts Construct ini*alizer 2

33 4.1 Syntax- directed transladon Parsing control table M decides which producdon to use So far: recorded producdon General: aoach code producdon E.g., add node to syntax tree E.g., keep track of defini*ons As the parser recognizes a word it produces an AST (or other desired data structure) or computes predicate 3

34 AOribute grammars Context free grammar extended with (context- sensidve) informadon ALributes ALached to non- terminals AOributes have values Value assigned during parsing Value evaluated in condi*onal stmt Synthesized aoributes Value obtained from alributes of children of non- terminal Inherited aoributes Value obtained from alribute of parent of non- terminal Or: of sibling(s) 4

35 Example (expression evaluadon) E à E + T ProducDon: E 0 à E 1 + T AOribute: Integer value E 0.Value := E 1.Value + T.Value Note: E 1 vs E 0 to disdnguish two occurrences of E in producdon 5

36 AOributes Consider L = { a n b n c n }. Terminals: a, b, c n integer 1 L cannot be produced by a context- free grammar We would like to use a context free grammar (and parser) to recognize L. Use alributes to deal with aspects parser cannot handle ALribute domain: integers, result predicate true if w = a k b k c k for some k. 6

37 Consider G S à A B C A à aa a B à bb b C à cc c Start symbol is S L = { a n b n c n } L(G) 7

38 Rules AOach to each producdon a rule Rules for A producdons A 0 à a A 1 <A 0 >.Na = <A 1 >.Na + 1 A à a <A>.Na = 1 Rules for B, C producdons similar CondiDon for S! A B C <A>.Na = <B>.Nb = <C>.Nc 8

39 aabbcc $ a$ aa$ Aa$ A$ ba$ bba$ BbA$ BA$ aabbcc$ abbcc$ bbcc$ bcc$ cc$ Na=1 Na=2 Nb=1 Nb=2 9

40 aabbcc BA$ cba$ ccba$ CcBA$ CBA$ S$ cc$ c$ $ Nc=1 Nc=2 true Na=Nb=Nc accept 10

41 aabbcc tree view S Condi4on: true Na = 2 A Nb = 2 B Nc = 2 C a A b B c Na = 1 Nb = 1 Nc = 1 C a b c 11

42 Powerful tool Easy to get carried away Once a topic of acdve research 12

Conflicts in LR Parsing and More LR Parsing Types

Conflicts in LR Parsing and More LR Parsing Types Lecture 10 Dr. Sean Peisert ECS 142 Spring 2009 1 Status Project 2 Due Friday, Apr. 24, 11:55pm The usual lecture time is being replaced by a discussion