Compilation Lecture 4: Syntax Analysis Bottom Up parsing Noam Rinetzky 1 The Real Anatomy of a Compiler Executable code exe Source text txt Lexical Analysis Sem. Analysis Process text input characters Syntax Analysis tokens AST Intermediate code generation Annotated AST Intermediate code optimization IR Code generation IR Target code optimization Symbolic Instructions SI Machine code generation Write executable output MI 2 Syntax Analysis Bottom-Up Parsing Goal: Build a parse tree Report error if input is not a legal program How: Read input left-to-right Construct a subtree for the first left-most tree node whose childern have been constructed 3 +*321 4 Bottom-up parsing E E * T E T T T + F T F F id F num F ( E ) E E T T F T F F (Non standard precedence) Bottom-up parsing: LR(k) Grammars A grammar is in the class LR(K) when it can be derived via: Bottom-up derivation Scanning the input from left to right (L) Producing the rightmost derivation (R) In reverse oreder With lookahead of k tokens (k) A language is said to be LR(k) if it has an LR(k) grammar The simplest case is LR(0), which we will discuss 5 Terminology: Reductions & Handles The opposite of derivation is called reduction Let A be a production rule Derivation: A Reduction: A A handle is the reduced substring is the handles for 6 Use Shift & Reduce In each stage, we shift a symbol from the input to the stack, or reduce according to one of the rules. 7 Stack Parser Input Output Action Table Goto table 8 )x*)7+23(( RPIdOPRPNumOPNumLP token stream Op(*) Id(b) Num(23)Num(7) Op(+) How does the parser know what to do? A state will keep the info gathered on handle(s) A state in the control of the PDA Also (part of) the stack alpha bet A table will tell it what to do based on current state and next token The transition function of the PDA A stack will records the nesting level Stack contains a sequence of prefixes of handles 9 Set of LR(0) items Important Bottom-Up LR-Parsers LR(0) simplest, explains basic ideas SLR(1) simple, exaplins lookahead LR(1) complictated, very powerful, expensive LALR(1) complicated, powerful enough, used by automatic tools 10 LR(0) vs SLR(1) vs LR(1) vs LALR(1) All use shift / reduce Main difference: how to identify a handle Technically: Using different sets of states More expsensive more states more specific choice of which reduction rule to use But the usage of the states is the same in all parsers Reduction is the same in all techniques Once the handle is determined 11 LR(0) Parsing 12 LR item 13 N Already matched To be matched Input Hypothesis about being a possible handle: so far weve matched , expecting to see Example: LR(0) Items All items can be obtained by placing a dot at every position for every production: 14 (1) S E $ (2) E T (3) E E + T (4) T id (5) T ( E ) 1: S E$ 2: S E $ 3: S E $ 4: E T 5: E T 6: E E + T 7: E E + T 8: E E + T 9: E E + T 10: T i 11: T i 12: T (E) 13: T ( E) 14: T (E ) 15: T (E) Grammar LR(0) items 15 N Shift Item N Reduce Item States are sets of items LR(0) automaton example 16 Z E$ E T E E + T T i T (E) T ( E) E T E E + T T i T (E) E E + T T (E) Z E$ Z E $ E E + T E E+ T T i T (E) T i T (E ) E E +T E T q0q0 q1q1 q2q2 q3q3 q4q4 q5q5 q6q6 q7q7 q8q8 q9q9 T ( i E + $ T ) + E i T ( i ( reduce state shift state read input ( Managed to reduce E States and LR(0) Items The state will remember the potential derivation rules given the part that was already identified For example, if we have already identified E then the state will remember the two alternatives: (1) E E * B, (2) E E + B Actually, we will also remember where we are in each of them: (1) E E * B, (2) E E + B A derivation rule with a location marker is called LR(0) item. The state is actually a set of LR(0) items. E.g., q 13 = { E E * B, E E + B} E E * B | E + B | B B 0 | 1 17 GOTO/ACTION tables 18 Statei+()$ETaction q0q5q7q1q6shift q1q3q2shift q2 Z E$ q3q5q7q4Shift q4 E E+T q5 T iT i q6 E TE T q7q5q7q8q6shift q8q3q9shift q9 T ET E GOTO Table ACTION Table empty = error move LR(0) parser tables Actions determined by topmost state Two types of rows: Shift row tells which state to GOTO for current token Reduce row tells which rule to reduce (independent of current token) GOTO entries are blank 19 GOTO/ACTION tables 20 Statei+()$ETaction q0q5q7q1q6shift q1q3q2shift q2 Z E$ q3q5q7q4Shift q4 E E+T q5 T iT i q6 E TE T q7q5q7q8q6shift q8q3q9shift q9 T ET E GOTO Table ACTION Table empty = error move GOTO/ACTION table action shift Z E$ Shift E E+T T iT i E TE T shift T ET E 21 Statei+()$ET q0s5s7s1s6 q1s3s2 q2r1 q3s5s7s4 q4r3 q5r4 q6r2 q7s5s7s8s6 q8s3s9 q9r5 (1)Z E $ (2)E T (3)E E + T (4)T i (5)T ( E ) Warning: numbers mean different things! rn = reduce using rule number n sm = shift to state m LR(0) Parsing of i + i Stack q0 q0 i q5 q0 T q6 q0 E q1 q0 E q1 + q3 q0 E q1 + q3 i q5 q0 E q1 + q3 T q4 q0 E q1 q0 E q1 $ q2 q0 $ 22 Statei+()$ET q0s5s7s1s6 q1s3s2 q2r1 q3s5s7s4 q4r3 q5r4 q6r2 q7s5s7s8s6 q8s3s9 q9r5 (1)Z E $ (2)E T (3)E E + T (4)T i (5)T ( E ) Warning: numbers mean different things! rn = reduce using rule number n sm = shift to state m input i + i $ + i $ i $ $ Action shift reduce 4 reduce 2 shift reduce 4 reduce 3 shift reduce 1 accept Constructing an LR parsing table Construct a (determinized) transition diagram from LR items If there are conflicts stop Fill table entries from diagram 23 LR item 24 N Already matched To be matched Input Hypothesis about being a possible handle, so far weve matched , expecting to see Types of LR(0) items 25 N Shift Item N Reduce Item LR(0) automaton example 26 Z E$ E T E E + T T i T (E) T ( E) E T E E + T T i T (E) E E + T T (E) Z E$ Z E $ E E + T E E+ T T i T (E) T i T (E ) E E +T E T q0q0 q1q1 q2q2 q3q3 q4q4 q5q5 q6q6 q7q7 q8q8 q9q9 T ( i E + $ T ) + E i T ( i ( reduce state shift state Computing item sets Initial set Z is in the start symbol -closure({ Z | Z is in the grammar } ) Next set from a set S and the next symbol X step(S,X) = { N X | N X in the item set S} nextSet(S,X) = -closure(step(S,X)) 27 Operations for transition diagram construction Initial = {S S$} For an item set I Closure(I) = Closure(I) {X is in grammar| N X in I} Goto(I, X) = { N X | N X in I} 28 Initial example Initial = {S E $} 29 (1) S E $ (2) E T (3) E E + T (4) T id (5) T ( E ) Grammar Closure example Initial = {S E $} Closure({S E $}) = { S E $ E T E E + T T id T ( E ) } 30 (1) S E $ (2) E T (3) E E + T (4) T id (5) T ( E ) Grammar Goto example Initial = {S E $} Closure({S E $}) = { S E $ E T E E + T T id T ( E ) } Goto({S E $, E E + T, T id}, E) = {S E $, E E + T} 31 (1) S E $ (2) E T (3) E E + T (4) T id (5) T ( E ) Grammar Constructing the transition diagram Start with state 0 containing item Closure({S E $}) Repeat until no new states are discovered For every state p containing item set Ip, and symbol N, compute state q containing item set Iq = Closure(goto(Ip, N)) 32 LR(0) automaton example 33 Z E$ E T E E + T T i T (E) T ( E) E T E E + T T i T (E) E E + T T (E) Z E$ Z E $ E E + T E E+ T T i T (E) T i T (E ) E E +T E T q0q0 q1q1 q2q2 q3q3 q4q4 q5q5 q6q6 q7q7 q8q8 q9q9 T ( i E + $ T ) + E i T ( i ( reduce state shift state Automaton construction example 34 (1) S E $ (2) E T (3) E E + T (4) T id (5) T ( E ) S E$ q0q0 Initialize 35 (1) S E $ (2) E T (3) E E + T (4) T id (5) T ( E ) S E$ E T E E + T T i T (E) q0q0 apply Closure Automaton construction example 36 (1) S E $ (2) E T (3) E E + T (4) T id (5) T ( E ) S E$ E T E E + T T i T (E) q0q0 E T q6q6 T T ( E) E T E E + T T i T (E) ( T i q5q5 i S E $ E E + T q1q1 E 37 (1) S E $ (2) E T (3) E E + T (4) T id (5) T ( E ) S E$ E T E E + T T i T (E) T ( E) E T E E + T T i T (E) E E + T T (E) S E$ Z E $ E E + T E E+ T T i T (E) T i T (E ) E E +T E T q0q0 q1q1 q2q2 q3q3 q4q4 q5q5 q6q6 q7q7 q8q8 q9q9 T ( i E + $ T ) + E i T ( i ( terminal transition corresponds to shift action in parse table non-terminal transition corresponds to goto action in parse table a single reduce item corresponds to reduce action Automaton construction example Are we done? Can make a transition diagram for any grammar Can make a GOTO table for every grammar Cannot make a deterministic ACTION table for every grammar 38 LR(0) conflicts 39 Z E $ E T E E + T T i T ( E ) T i[E] Z E$ E T E E + T T i T (E) T i[E] T i T i [E] q0q0 q5q5 T ( i E Shift/reduce conflict LR(0) conflicts 40 Z E $ E T E E + T T i V i T ( E ) Z E$ E T E E + T T i T (E) T i[E] T i V i q0q0 q5q5 T ( i E reduce/reduce conflict LR(0) conflicts Any grammar with an -rule cannot be LR(0) Inherent shift/reduce conflict A reduce item P A shift item A can always be predicted from P A 41 Conflicts Can construct a diagram for every grammar but some may introduce conflicts shift-reduce conflict: an item set contains at least one shift item and one reduce item reduce-reduce conflict: an item set contains two reduce items 42 LR variants LR(0) what weve seen so far SLR(0) Removes infeasible reduce actions via FOLLOW set reasoning LR(1) LR(0) with one lookahead token in items LALR(0) LR(1) with merging of states with same LR(0) component 43 LR (0) GOTO/ACTIONS tables 44 Statei+()$ETaction q0q5q7q1q6shift q1q3q2shift q2 Z E$ q3q5q7q4Shift q4 E E+T q5 T iT i q6 E TE T q7q5q7q8q6shift q8q3q9shift q9 T ET E GOTO Table ACTION Table ACTION table determined only by state, ignores input GOTO table is indexed by state and a grammar symbol from the stack SLR parsing A handle should not be reduced to a non-terminal N if the lookahead is a token that cannot follow N A reduce item N is applicable only when the lookahead is in FOLLOW(N) If b is not in FOLLOW(N) we proved there is no derivation S * Nb. Thus, it is safe to remove the reduce item from the conflicted state Differs from LR(0) only on the ACTION table Now a row in the parsing table may contain both shift actions and reduce actions and we need to consult the current token to decide which one to take 45 SLR action table 46 Statei+()[]$ 0shift 1 accept 2 3shift 4 E E+T 5 T iT iT iT i shift T iT i 6 E TE TE TE TE TE T T (E) vs. stateaction q0shift q1shift q2 q3shift q4 E E+T q5 T iT i q6 E TE T q7shift q8shift q9 T ET E SLR use 1 token look-aheadLR(0) no look-ahead as before T i T i[E] Lookahead token from the input LR(1) grammars In SLR: a reduce item N is applicable only when the lookahead is in FOLLOW(N) But FOLLOW(N) merges lookahead for all alternatives for N Insensitive to the context of a given production LR(1) keeps lookahead with each LR item Idea: a more refined notion of follows computed per item 47 LR(1) items LR(1) item is a pair LR(0) item Lookahead token Meaning We matched the part left of the dot, looking to match the part on the right of the dot, followed by the lookahead token Example The production L id yields the following LR(1) items 48 [L id, *] [L id, =] [L id, id] [L id, $] [L id , *] [L id , =] [L id , id] [L id , $] (0) S S (1) S L = R (2) S R (3) L * R (4) L id (5) R L [L id] [L id ] LR(0) items LR(1) items LR(1) item is a pair LR(0) item Lookahead token Meaning We matched the part left of the dot, looking to match the part on the right of the dot, followed by the lookahead token Example The production L id yields the following LR(1) items Reduce only if the the expected lookhead matches the input [L id , =] will be used only if the next input token is = 49 LALR(1) LR(1) tables have huge number of entries Often dont need such refined observation (and cost) Idea: find states with the same LR(0) component and merge their lookaheads component as long as there are no conflicts LALR(1) not as powerful as LR(1) in theory but works quite well in practice Merging may not introduce new shift-reduce conflicts, only reduce-reduce, which is unlikely in practice 50 Summary 51 LR is More Powerful than LL Any LL(k) language is also in LR(k), i.e., LL(k) LR(k). LR is more popular in automatic tools But less intuitive Also, the lookahead is counted differently in the two cases In an LL(k) derivation the algorithm sees the left-hand side of the rule + k input tokens and then must select the derivation rule In LR(k), the algorithm sees all right-hand side of the derivation rule + k input tokens and then reduces LR(0) sees the entire right-side, but no input token 52 terminal Integer NUMBER; terminal PLUS,MINUS,MULT,DIV; terminal LPAREN, RPAREN; terminal UMINUS; nonterminal Integer expr; precedence left PLUS, MINUS; precedence left DIV, MULT; Precedence left UMINUS; % expr ::= expr:e1 PLUS expr:e2 {: RESULT = new Integer(e1.intValue() + e2.intValue()); :} | expr:e1 MINUS expr:e2 {: RESULT = new Integer(e1.intValue() - e2.intValue()); :} | expr:e1 MULT expr:e2 {: RESULT = new Integer(e1.intValue() * e2.intValue()); :} | expr:e1 DIV expr:e2 {: RESULT = new Integer(e1.intValue() / e2.intValue()); :} | MINUS expr:e1 %prec UMINUS {: RESULT = new Integer(0 - e1.intValue(); :} | LPAREN expr:e1 RPAREN {: RESULT = e1; :} | NUMBER:n {: RESULT = n; :} 53 Using tools to parse + create AST Grammar Hierarchy 54 Non-ambiguous CFG LR(1) LALR(1) SLR(1) LL(1) LR(0) Earley Parsing 55 Jay Earley, PhD Earley Parsing Invented by Jay Earley [PhD. 1968] Handles arbitrary context free grammars Can handle ambiguous grammars Complexity O(N 3 ) when N = |input| Uses dynamic programming Compactly encodes ambiguity 56 Dynamic programming Break a problem P into subproblems P 1 P k Solve P by combining solutions for P 1 P k Memo-ize (store) solutions to subproblems instead of re-computation Bellman-Ford shortest path algorithm Sol(x,y,i) = minimum of Sol(x,y,i-1) Sol(t,y,i-1) + weight(x,t) for edges (x,t) 57 Earley Parsing Dynamic programming implementation of a recursive descent parser S[N+1] Sequence of sets of Earley states N = |INPUT| Earley state (item) s is a sentential form + aux info S[i] All parse tree that can be produced (by a RDP) after reading the first i tokens S[i+1] built using S[0] S[i] 58 Earley Parsing Parse arbitrary grammars in O(|input| 3 ) O(|input| 2 ) for unambigous grammer Linear for most LR(k) langaues Dynamic programming implementation of a recursive descent parser S[N+1] Sequence of sets of Earley states N = |INPUT| Earley states is a sentential form + aux info S[i] All parse tree that can be produced (by an RDP) after reading the first i tokens S[i+1] built using S[0] S[i] 59 Earley States s = constituent (dotted rule) for A A predicated constituents A in-progress constituents A completed constituents back previous Early state in derivation 60 Earley States s = constituent (dotted rule) for A A predicated constituents A in-progress constituents A completed constituents back previous Early state in derivation 61 Earley Parser Input = x[1N] S[0] = ; S[1] = S[N] = {} for i = 0... N do until S[i] does not change do foreach s S[i] if s = and a=x[i+1] then // scan S[i+1] = S[i+1] { } if s = and X then // predict S[i] = S[i] { } if s = and S[b] then // complete S[i] = S[i] { } 62 Example 63 if s = and a=x[i+1] then // scan S[i+1] = S[i+1] { } if s = and X then // predict S[i] = S[i] { } if s = and S[b] then // complete S[i] = S[i] { } Compilation 64 Semantic Analysis Noam Rinetzky You are here 65 Executable code exe Source text txt Lexical Analysis Semantic Analysis Process text input characters Syntax Analysis tokens AST Intermediate code generation Annotated AST Intermediate code optimization IR Code generation IR Target code optimization Symbolic Instructions SI Machine code generation Write executable output MI Back End Oops int x; xx = 0; int x, y; z = x + 1; main() { break; } int x; print(x) 66 Can the parser help? 0 or 1 this is the question int x = 0; p() { print(x) } q() { int x = 1; p() } 67 Can the parser help? We want help Semantic (Context) analysis to the rescue 68 Semantic Analysis Syntax Analysis AST We want help Semantic (Context) analysis to the rescue 69 Semantic Analysis Syntax Analysis AST Abstract Syntax Tree AST is a simplification of the parse tree Can be built by traversing the parse tree E.g., using visitors Can be built directly during parsing Add an action to perform on each production rule Similarly to the way a parse tree is constructed 70 Abstract Syntax Tree The interface between the parser and the rest of the compiler Separation of concerns Reusable, modular and extensible The AST is defined by a context free grammar The grammar of the AST can be ambiguous! E E + E Is this a problem? Keep syntactic information Why? 71 What we want symbolkindtypeproperties xvar? tomatovar? potatovarPotato carrotvarCarrot 72 Lexical analyzer Potato potato; Carrot carrot; x = tomato + potato + carrot ,,,,,EOF Parser tomato is undefinedpotato used before initializedCannot add Potato and Carrot LocationExpr id=tomato AddExpr leftright AddExpr leftright LocationExpr id=potatoid=carrot LocationExpr Context Analysis Check properties contexts of in which constructs occur Properties that cannot be formulated via CFG Type checking Declare before use Identifying the same word w re-appearing wbw Initialization Properties that are hard to formulate via CFG break only appears inside a loop Processing of the AST 73 Context Analysis Identification Gather information about each named item in the program e.g., what is the declaration for each usage Context checking Type checking e.g., the condition in an if-statement is a Boolean 74 Identification 75 month : integer RANGE [1..12]; month := 1; while (month =} E1 : booleanE2 : boolean E1 lop E2 : boolean lop { &&,|| } E1 : boolean !E1 : boolean Type Declarations So far, we ignored the fact that types can also be declared 98 TYPE Int_Array = ARRAY [Integer 1..42] OF Integer; Var a : ARRAY [Integer 1..42] OF Real; (explicitly) (anonymously) 99 Var a : ARRAY [Integer 1..42] OF Real; TYPE #type01_in_line_73 = ARRAY [Integer 1..42] OF Real; Var a : #type01_in_line_73; Type Declarations Forward References Forward references must be resolved A forward references added to the symbol table as forward reference, and later updated when type declaration is met At the end of scope, must check that all forward references have been resolved Check must be added for circularity 100 TYPE Ptr_List_Entry = POINTER TO List_Entry; TYPE List_Entry = RECORD Element : Integer; Next : Ptr_List_Entry; END RECORD; Type Table All types in a compilation unit are collected in a type table For each type, its table entry contains: Type constructor: basic, record, array, pointer, Size and alignment requirements to be used later in code generation Types of components (if applicable) e.g., types of record fields 101 Type Equivalence: Name Equivalence t1 not (name) equivalence to t2 102 Type t1 = ARRAY[Integer] OF Integer; Type t2 = ARRAY[Integer] OF Integer; t3 equivalent to t4 Type t3 = ARRAY[Integer] OF Integer; Type t4 = t3 Type Equivalence: Structural Equivalence t5, t6, t7 are all (structurally) equivalent 103 Type t5 = RECORD c: Integer; p: POINTER TO t5; END RECORD; Type t6 = RECORD c: Integer; p: POINTER TO t6; END RECORD; Type t7 = RECORD c: Integer; p: POINTER TO RECORD c: Integer; p: POINTER to t5; END RECORD; END RECORD; In practice Almost all modern languages use name equivalence 104 Coercions If we expect a value of type T1 at some point in the program, and find a value of type T2, is that acceptable? 105 float x = 3.141; int y = x; l-values and r-values What is dst? What is src? dst is a memory location where the value should be stored src is a value location on the left of the assignment called an l-value value on the right of the assignment is called an r-value 106 dst := src l-values and r-values (example) 107 x:= y x x47 x y 17 0x x47 x y l-values and r-values 108 lvaluervalue lvalue-deref rvalueerror- expected found So far Static correctness checking Identification Type checking Identification matches applied occurrences of identifier to its defining occurrence The symbol table maintains this information Type checking checks which type combinations are legal Each node in the AST of an expression represents either an l-value (location) or an r-value (value) 109 How does this magic happen? We probably need to go over the AST? how does this relate to the clean formalism of the parser? 110 Syntax Directed Translation Semantic attributes Attributes attached to grammar symbols Semantic actions How to update the attributes Attribute grammars 111 Attribute grammars Attributes Every grammar symbol has attached attributes Example: Expr.type Semantic actions Every production rule can define how to assign values to attributes Example: Expr Expr + Term Expr.type = Expr1.type when (Expr1.type == Term.type) Error otherwise 112 Indexed symbols Add indexes to distinguish repeated grammar symbols Does not affect grammar Used in semantic actions Expr Expr + Term Becomes Expr Expr1 + Term 113 Example 114 ProductionSemantic Rule D T LL.in = T.type T intT.type = integer T floatT.type = float L L1, idL1.in = L.in addType(id.entry,L.in) L idaddType(id.entry,L.in) D D float L L L L id1 T T L L id2 id3 float x,y,z float Attribute Evaluation Build the AST Fill attributes of terminals with values derived from their representation Execute evaluation rules of the nodes to assign values until no new values can be assigned In the right order such that No attribute value is used before its available Each attribute will get a value only once 115 Dependencies A semantic equation a = b1,,bm requires computation of b1,,bm to determine the value of a The value of a depends on b1,,bm We write a bi 116 Cycles Cycle in the dependence graph May not be able to compute attribute values 117 T T E E E.s = T.i T.i = E.s + 1 T.i E.s ASTDependence graph Attribute Evaluation Build the AST Build dependency graph Compute evaluation order using topological ordering Execute evaluation rules based on topological ordering Works as long as there are no cycles 118 Building Dependency Graph All semantic equations take the form attr1 = func1(attr1.1, attr1.2,) attr2 = func2(attr2.1, attr2.2,) Actions with side effects use a dummy attribute Build a directed dependency graph G For every attribute a of a node n in the AST create a node n.a For every node n in the AST and a semantic action of the form b = f(c1,c2,ck) add edges of the form (ci,b) 119 Example 120 ProductionSemantic Rule D T L L.in = T.type T int T.type = integer T float T.type = float L L1, id L1.in = L.in addType(id.entry,L.in) L id addType(id.entry,L.in) ProductionSemantic Rule D T L L.in = T.type T int T.type = integer T float T.type = float L L1, id L1.in = L.in L.dmy = addType(id.entry,L.in) L id L.dmy = addType(id.entry,L.in) Convention: Add dummy variables for side effects. Example 121 Prod.Semantic Rule D T LL.in = T.type T intT.type = integer T floatT.type = float L L1, idL1.in = L.in addType(id.entry,L.in) L idaddType(id.entry,L.in) D D float L L L L id1 T T L L id2 id3 float x,y,z type in dmy entry in dmy Example 122 Prod.Semantic Rule D T LL.in = T.type T intT.type = integer T floatT.type = float L L1, idL1.in = L.in addType(id.entry,L.in) L idaddType(id.entry,L.in) D D float L L L L id1 T T L L id2 id3 float x,y,z type in dmy entry in dmy Topological Order For a graph G=(V,E), |V|=k Ordering of the nodes v1,v2,vk such that for every edge (vi,vj) E, i < j Example topological orderings: , Example 124 float x,y,z type in dmy entry in dmy float ent1 ent2 ent3 float But what about cycles? For a given attribute grammar hard to detect if it has cyclic dependencies Exponential cost Special classes of attribute grammars Our usual trick sacrifice generality for predictable performance 125 Inherited vs. Synthesized Attributes Synthesized attributes Computed from children of a node Inherited attributes Computed from parents and siblings of a node Attributes of tokens are technically considered as synthesized attributes 126 example 127 ProductionSemantic Rule D T LL.in = T.type T intT.type = integer T floatT.type = float L L1, idL1.in = L.in addType(id.entry,L.in) L idaddType(id.entry,L.in) D D float L L L L id1 T T L L id2 id3 float x,y,z float inherited synthesized S-attributed Grammars Special class of attribute grammars Only uses synthesized attributes (S-attributed) No use of inherited attributes Can be computed by any bottom-up parser during parsing Attributes can be stored on the parsing stack Reduce operation computes the (synthesized) attribute from attributes of children 128 S-attributed Grammar: example 129 ProductionSemantic Rule S E ;print(E.val) E E1 + TE.val = E1.val + T.val E TE.val = T.val T T1 * FT.val = T1.val * F.val T FT.val = F.val F (E)F.val = E.val F digitF.val = digit.lexval example F F T T E F F T T E * 7 7 F F T T S S Lexval=3 Lexval=4 Lexval=7 val=7 val=4 val=28 val=3 val=31 31 L-attributed grammars L-attributed attribute grammar when every attribute in a production A X1Xn is A synthesized attribute, or An inherited attribute of Xj, 1