Syntactic Directed Translation

Transcription

1 Sntactic Directed Translation What is Sntax-Directed Translation? Translation Process guided b Context-Free Grammars Attach Attributes to Grammar Smbols Attribute Grammars & Sntax-Directed Definitions Values and Semantic Rules Associated with Productions Attributive Grammar Two Flavors: Sntax-Directed Definitions (order is implicit; more abstract) Translation Schemes (explicit order; more concrete) Wh Use This? Ver Powerful Mechanism Used to Build Parse Tree Copright 2, Pedro C. Diniz, all rights reserved. Students enrolled in the Compilers class at the Universit of Southern California have explicit permission to make copies of these materials for their personal use. Perform Semantic Analsis such as Tpe Checking Generate Code 2 Attribute Grammars s What is an Attribute Grammar? A Context-Free Grammar Augmented with a Set of Rules Each Smbol in the derivation has a set of values, or Attributes The Rules specif How to Compute a value for each Attribute Grammar!! +!! This grammar describes signed binar numbers We would like to augment it with rules that compute the decimal value of each valid input string For For 3 4 Attribute Grammars Back to the s Add rules to compute the decimal value of a signed binar number Productions Attribution Rules!.pos " If.neg then.val ".val Smbol Attributes else.val ".val val! +.neg " false neg.neg " true pos, val!.pos ".pos +.pos ".pos.val ".val +.val pos, val.pos ".pos.val ".val!.val ".val " 2.pos For neg true.val.val.pos.val.val.pos.val 2.pos Possible data-flow model for Evaluation Independent Attributes First One possible evaluation order:.pos 2.neg 3.pos 4.val 5.val 6.val Other orders are possible Others in Order as Input Values become Available 5 6

2 Back to the s Rules + parse tree impl an attribute dependence graph Back to the s For neg true.val.val.pos.val.val.pos.val 2.pos Possible data-flow model for Evaluation Independent Attributes First One possible evaluation order:.pos 2.neg 3.pos 4.val 5.val 6.val Other orders are possible Others in Order as Input Values become Available Evaluation order must be consistent with the attribute dependence graph 5 neg: true For This is the complete attribute dependence graph for. It shows the flow of all attribute values in the example. Some flow downward Inherited Attributes Some flow upward Snthesized Attributes A rule ma use attributes in the parent, children, or siblings of a node 7 8 Using Attribute Grammars Using Attribute Grammars Attribute Grammars Can Specif Context-Sensitive Actions Take Values from Sntax Perform Computations with Values Insert Tests, Logic, Attribute Grammars Can Specif Context-Sensitive Actions Take Values from Sntax Perform Computations with Values Insert Tests, Logic, Snthesized Attributes Use values from self, children & from constants S-attributed grammars Evaluate in a single bottom-up pass Good match for LR parsing Inherited Attributes Use values from self, parent, siblings & constants Directl express context Can rewrite to avoid them Thought to be more natural Not easil done at parse time Snthesized Attributes Use values from self, children & from constants Good match for LR parsing Inherited Attributes Use values from self, parent, siblings & constants Not easil done at parse time 9 Attributes, Rules and Evaluation Order Evaluation Methods Attributes: Snthesized: Depend on Values from Children or Itself Inherited: Depend on Values from Parent, Siblings or Itself How to Determine the Evaluation Order of Rules? Construct the Parse Tree with Attributes Build an Attribute Dependence Graph Topological Sort It and Evaluate the Rules Dnamic, dependence-based methods Build the Parse Tree Build the Dependence Graph Topological Sort the Dependence Graph Evaluate Attributes in Topological Order Rule-based methods Analze Rules at Compiler-Generation Time Determine a Fixed (static) Ordering Evaluate Nodes in that Order (treewalk) Oblivious Methods Ignore Rules & Parse Tree Pick a Convenient Order (at design time) & Use It (passes, dataflow) 2 2

3 neg: For For 3 4 Inherited Attributes Snthesized Attributes neg: neg: true 4 For For Snthesized Attributes 5 If we show the computation... neg: true 5 neg: true & then peel awa the parse tree For For 7 8 3

4 neg: true For All that is left is the attribute dependence graph. The dependence graph must be acclic This succinctl represents the flow of values in the problem instance. The dnamic methods sort this graph to find independent values, then work along graph edges. The rule-based methods tr to discover good orders b analzing the rules. The oblivious methods ignore the structure of this graph. Circularit We can onl evaluate Acclic Instances We can prove that some grammars can onl generate instances with acclic dependence graphs Largest such class is strongl non-circular grammars (SNC ) SNC grammars can be tested in polnomial time Failing the SNC test is not conclusive Man evaluation methods discover circularit dnamicall Bad propert for a compiler to have SNC grammars were first defined b Kenned & Warren 9 2 A Circular Attribute Grammar Productions Attribution Rules!.a "!.a ".a +.b ".b.c ".b +.val.b ".a +.c +.val!.val ".val " 2.pos For.a.a +.b.b.c.b +.val.a.b.a +.c +.val.val.val 2.pos 2 22.a.a.a +.b.b.c.b +.val.b.a +.c +.val.a.a.a +.b.b.c.b +.val.b.a +.c +.val.val.val 2.pos.val.val 2.pos For For

5 .a.a +.b.b.c.b +.val.a.b.a +.c +.val.a.a +.b.b.c.b +.val.a.b.a +.c +.val.val.val 2.pos.val.val 2.pos For For Here is the circularit An : Estimating Ccle Counts For.a.a +.b.b.c.b +.val.a.b.a +.c +.val.val.val 2.pos Grammar for a Basic Block Block! Block "! Ident = Expr ; Expr! Expr + Term " Expr Term " Term Term! Term * Factor " Term / Factor " Factor Factor! ( Expr ) " " Identifier Assumptions: Each operation has a COST Add them, bottom up Assume a load per value Assume no reuse via registers Simple problem for an Attributive Grammar Here is the circularit An (continued)! Block Block Block.cost " Block.cost +.cost # Block.cost ".cost! Ident = Expr ;.cost " COST(store) + Expr.cost Expr! Expr + Term Expr.cost " Expr.cost + COST(add) + Term.cost # Expr Term Expr.cost " Expr.cost + COST(add) + Term.cost # Term Expr.cost " Term.cost Term! Term * Factor Term.cost " Term.cost + COST(mult ) + Factor.cost # Term / Factor Term.cost " Term.cost + COST(div) + Factor.cost # Factor Term.cost " Factor.cost Factor! ( Expr ) Factor.cost " Expr.cost # Factor.cost " COST(loadI) # Identifier Factor.cost " COST(load) These are all snthesized attributes! Values flow from RHS to LHS in prod ns x = + z = + z = x / 2 cost(loadi) = cost(load) = 2 cost(store) = 2 cost(add) = 3 cost(div) = 9 An (continued) Block Block Id = Expr Id = Expr Id = Expr z Expr / Term x Expr + Term Expr + Term Term Term Factor Term Factor Factor Factor num Factor Id Factor num Id 2 Id z Id x

6 An (continued) An (continued) Properties of the Grammar All Attributes are Snthesized S-Attributed Grammar Rules can be Evaluated Bottom-up in a Single Pass Good fit to bottom-up, shift/reduce parser Easil Understood Solution Seems to fit the Problem Well x = + z = + z = x / 2 cost(loadi) = cost(load) = 2 cost(store) = 2 cost(add) = 3 cost(div) = 9 Block 3 Block Id = Expr 2 Id = Expr Id = Expr 7 6 z Expr / Term 2 x Expr + Term Expr + Term Term Factor 2 Term Factor Term Factor Factor num 2 Factor Id Factor num 2 2 Id 2 Id z Id x 3 32 An Interesting - Tracking Loads A Better Execution Model Values are loaded onl once per block (not at each use) Need to track which values have been alread loaded Assumes an Infinite Register Set to Hold Variables Adding load tracking Need Sets Before and After for each production Must be initialized, updated, and passed around the tree Factor! ( Expr ) Factor.cost " Expr.cost ; Expr.Before " Factor.Before ; Factor.After " Expr.After # Factor.cost " COST(loadi) ; # Identifier If (Identifier.name $ Factor.Before) then Factor.cost " COST(load); % Identifier.name else Factor.cost " 33 This looks more complex! 34 An (continued) A Better Execution Model x = + z = + z = x / 2 cost(loadi) = cost(load) = 2 cost(store) = 2 cost(add) = 3 cost(div) = 9 { Block {,z { Block 5 {,z {,z 4 { 9 {,z 6 {x,,z {,z {,z Id = Expr 7 2 Id = Expr Id = Expr 4 {,z {,z {x,,z { {,z {,z z Expr / Term 2 x Expr + Term Expr + Term {,z {x,,z {x,,z 2 2 { Term Factor { { {,z {,z {,z {,z {,z 2 Term { Factor 2 Term Factor {x,,z 2 {,z Factor num { {,z {,z {,z 2 Factor Id Factor num {x,,z 2 Id { {,z 2 {,z Id z Id x 29 {x,,z Load tracking adds complexit But, most of it is in the cop rules Ever production needs rules to cop Before & After A sample production Expr! Expr + Term Expr.cost " Expr.cost + COST(add) + Term.cost ; Expr.Before " Expr.Before ; Term.Before " Expr.After; Expr.After " Term.After These cop rules multipl rapidl Each creates an instance of the set Lots of work, lots of space, lots of rules to write

7 An Even Better Model The Moral of the Stor What about accounting for Finite Register Sets? Before & After must be of Limited Size Adds complexit to Factor Identifier Requires more Complex Initialization Jump from Tracking Loads to Tracking Registers is small Cop rules are alread in place Some local code to perform the Allocation Non-local computation needed lots of supporting rules Complex local computation was relativel eas The Problems Cop rules increase cognitive overhead Cop rules increase space requirements Need copies of attributes Can use pointers, for even more cognitive overhead Result is an attributed tree (somewhat subtle points) Must build the parse tree Either search tree for answers or cop them to the root Addressing the Problem Reworking the (with load tracking) If ou gave this problem to a real programmer Introduce a central repositor for facts Table of names Field in table for loaded/not loaded state Avoids all the cop rules, allocation & storage headaches All inter-assignment attribute flow is through table Clean, efficient implementation Good techniques for implementing the table When its done, information is in the table! Cures most of the problems Unfortunatel, this design violates the functional paradigm Do we care? Block! Block " cost # ;! Ident = Expr ; cost# cost + COST(store); Expr! Expr + Term cost# cost + COST(add); " Expr Term cost# cost + COST(sub); " Term Term! Term * Factor cost# cost + COST(mult); " Term / Factor cost# cost + COST(div); " Factor Factor! ( Expr ) " cost# cost + COST(loadi); " Identifier { i# hash(identifier); if (Table[i].loaded = false ) then { cost # cost + COST(load); Table[i].loaded # true; This looks cleaner & simpler! 39 4 Reworking the (with load tracking Factor! ( Expr ) " cost# cost + COST(loadi); " Identifier { i# hash(identifier); if (Table[i].loaded = false) then { cost # cost + COST(load) ; Table[i].loaded # true;! Expr ) Factor.cost " Expr.cost ; Factor ( Expr.Before " Factor.Before ; Factor.After " Expr.After # Factor.cost " COST(loadi) ; # Identifier If (Identifier.name $ Factor.Before) then Factor.cost " COST(load); % Identifier.name else Factor.cost " Attribute Grammar Summar Augment CFG with Attributes and Rules Inherited and Snthesized Attributes Sntax-Directed Definitions Find Dependence Graph and Evaluation Order Useful for Semantic Analsis