1 / 86

Compiler Construction

This article discusses the concepts of syntax-directed translation, semantics, and attribute grammars in compiler construction. It covers topics such as SDDs, synthesized and inherited attributes, semantic rules, and dependency graphs.

frederickc
Download Presentation

Compiler Construction

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Compiler Construction 강의 8

  2. LR(k) ≡ LR(1) Context-Free Languages Context-free languages Deterministic languages (LR(k)) LL(k) languages Simple precedence languages Operator precedence languages LL(1) languages The inclusion hierarchy for context-free languages

  3. Context-Free Grammars Context-free grammars Floyd-Evans Parsable Unambiguous CFGs Operator Precedence LR(k) LL(k) • Operator precedence includes some ambiguous grammars • LL(1) is a subset of SLR(1) LR(1) LALR(1) SLR(1) LL(1) The inclusion hierarchy for context-free grammars LR(0)

  4. Beyond Syntax • There is a level of correctness that is deeper than grammar fie(a,b,c,d) int a, b, c, d; { … } fee() { int f[3],g[0], h, i, j, k; char *p; fie(h,i,“ab”,j, k); k = f * i + j; h = g[17]; printf(“<%s,%s>.\n”, p,q); p = 10; } What is wrong with this program? (let me count the ways …)

  5. Semantics • There is a level of correctness that is deeper than grammar fie(a,b,c,d) int a, b, c, d; { … } fee() { int f[3],g[0], h, i, j, k; char *p; fie(h,i,“ab”,j, k); k = f * i + j; h = g[17]; printf(“<%s,%s>.\n”, p,q); p = 10; } What is wrong with this program? (let me count the ways …) • declared g[0], used g[17] • wrong number of args to fie() •“ab” is not an int • wrong dimension on use of f • undeclared variable q • 10 is not a character string All of these are “deeper than syntax”

  6. Syntax-directed translation • In syntax-directed translation, we attach ATTRIBUTES to grammar symbols. • The values of the attributes are computed by SEMANTIC RULES associated with grammar productions. • Conceptually, we have the following flow: • In practice, however, we do everything in a single pass.

  7. Syntax-directed translation • There are two ways to represent the semantic rules we associate with grammar symbols. • SYNTAX-DIRECTED DEFINITIONS (SDDs) do not specify the order in which semantic actions should be executed • TRANSLATION SCHEMES explicitly specify the ordering of the semantic actions. • SDDs are higher level; translation schemes are closer to • an implementation

  8. Syntax-Directed Definitions

  9. Syntax-directed definitions • The SYNTAX-DIRECTED DEFINITION (SDD) is a generalization of the context-free grammar. • Each grammar symbol in the CFG is given a set of ATTRIBUTES. • Attributes can be any type (string, number, memory loc, etc) • SYNTHESIZED attributes are computed from the values of the CHILDREN of a node in the parse tree. • INHERITED attributes are computed from the attributes of the parents and/or siblings of a node in the parse tree.

  10. Attribute dependencies • Given a SDD, we can describe the dependencies between the attributes with a DEPENDENCY GRAPH. • A parse tree annotated with attributes is called an ANNOTATED parse tree. • Computing the attributes of the nodes in a parse tree is called ANNOTATING or DECORATING the tree.

  11. Form of a syntax-directed definition • In a SDD, each grammar production A -> α has associated with it semantic rules • b := f( c1, c2, …, ck ) • where f() is a function, and either • b is a synthesized attribute of A, and c1, c2, …, are attributes of the grammar symbols of α, or • b is an inherited attribute of one of the symbols on the RHS, and c1, c2, … are attributes of the grammar symbols of α • in either case, we say b DEPENDS on c1, c2, …, ck.

  12. Semantic rules • Usually we actually write the semantic rules with expressions instead of functions. • If the rule has a SIDE EFFECT, e.g. updating the symbol table, we write the rule as a procedure call. • When a SDD has no side effects, we call it an ATTRIBUTE GRAMMAR (Programming Languages course에서 설명).

  13. Synthesized attributes • Synthesized attributes depend only on the attributes of • children. They are the most common attribute type. • If a SDD has synthesized attributes ONLY, it is called a S-ATTRIBUTED DEFINITION. • S-attributed definitions are convenient since theattributes can be calculated in a bottom-up traversal of the parse tree.

  14. Example SDD: desk calculator • ProductionSemantic Rule • L -> E newline print( E.val ) • E -> E1 + T E.val := E1.val + T.val • E -> T E.val := T.val • T -> T1 * F T.val := T1.val x F.val • T -> F T.val := F.val • F -> ( E ) F.val := E.val • F -> number F.val := number.lexval • Notice the similarity to the yacc spec from last lecture.

  15. Calculating synthesized attributes Input string: 3*5+4 newline Annotated tree:

  16. Inherited attributes • An inherited attribute is defined in terms of theattributes of the node’s parents and/or siblings. • Inherited attributes are often used in compilers for passing contextual information forward, for example, the type keyword in a variable declaration statement.

  17. Example SDD with an inherited attribute • Suppose we want to describe decls like “real x, y, z” • Production Semantic Rules • D -> T L L.in := T.type • T -> int T.type := integer • T -> real T.type := real • L -> L1, id L1.in := L.in • addtype( id.entry, L.in ) • L -> id addtype( id.entry, L.in ) • L.in is inherited since it depends on a sibling or parent. addtype() is just a procedure that sets the type field in the symbol table.

  18. Annotated parse tree for real id1, id2, id3 What are the dependencies?

  19. Dependency Graphs

  20. Dependency graphs • If an attribute b depends on attribute c, then attribute b has to be evaluated AFTER c. • DEPENDENCY GRAPHS visualize these requirements. • Each attribute is a node • We add edges from the node for attribute c to the node for attribute b, if b depends on c. • For procedure calls, we introduce a dummy synthesized attribute that depends on the parameters of the procedure calls.

  21. Dependency graph example • ProductionSemantic Rule • E -> E1 + E2 E.val := E1.val + E2.val • Wherever this rule appears in the parse, tree we draw:

  22. Example dependency graph

  23. Example dependency graph

  24. Finding a valid evaluation order • A TOPOLOGICAL SORT of a directed acyclic graph orders the nodes so that for any nodes a and b such that a -> b, a appears BEFORE b in the ordering. • There are many possible topological orderings for a DAG. • Each of the possible orderings gives a valid order for evaluation of the semantic rules.

  25. Example dependency graph

  26. Syntax Trees

  27. Application: syntax tree construction • One thing SDDs are useful for is construction of SYNTAX TREES. • Recall from Lecture 1 that a syntax tree is a condensed form of parse tree. • Syntax trees are useful for representing programming language constructs like expressions and statements. • They help compiler design by decoupling parsing from translation.

  28. Syntax trees • Leaf nodes for operators and keywords are removed. • Internal nodes corresponding to uninformative non-terminals are replaced by the more meaningful operators.

  29. SDD for syntax tree construction • We need some functions to help us build the syntax tree: • mknode(op,left,right) constructs an operator node with label op, and two children, left and right • mkleaf(id,entry) constructs a leaf node with label id and a pointer to a symbol table entry • mkleaf(num,val) constructs a leaf node with label num and the token’s numeric value val • Use these functions to build a syntax tree for a-4+c: • P1 := mkleaf( id, st_entry_for_a ) • P2 := …

  30. SDD for syntax tree construction • ProductionSemantic Rules • E -> E1 + T E.nptr := mknode( ‘+’, E1.nptr,T.nptr) • E -> E1 - T E.nptr := mknode( ‘-’, E1.nptr,T.nptr) • E -> T E.nptr := T.nptr • T -> ( E ) T.nptr := E.nptr • T -> id T.nptr := mkleaf( id, id.entry ) • T -> num T.nptr := mkleaf( num, num.val ) • Note that this is a S-attributed definition. • Try to derive the annotated parse tree for a-4+c.

  31. Evaluating SDDs Bottom-up

  32. Bottom-up evaluation of S-attributed defn • How can we build a translator for a given SDD? • For S-attributed definitions, it’s pretty easy! • A bottom-up shift-reduce parser can evaluate the (synthesized) attributes as the input is parsed. • We store the computed attributes with the grammar symbols and states on the stack. • When a reduction is made, we calculate the values of any synthesized attributes using the already-computed attributes from the stack.

  33. Bottom-up evaluation of S-attributed defns • In the scheme, our parser’s stack now stores grammar symbols AND attribute values. • For every production A -> XYZ with semantic rule A.a := f( X.x, Y.y, Z.z ), before XYZ is reduced to A, we should already have X.x Y.y and Z.z on the stack.

  34. Desk calculator example • If attribute values are placed on the stack as described, it is now easy to implement the semantic rules for the desk calculator. • ProductionSemantic RuleCode • L -> E newline print( E.val ) print val[top-1] • E -> E1 + T E.val := E1.val + T.val val[newtop] = val[top-2]+val[top] • E -> T E.val := T.val /*newtop==top, so nothing to do*/ • T -> T1 * F T.val := T1.val x F.val val[newtop] = val[top-2]+val[top] • T -> F T.val := F.val /*newtop==top, so nothing to do*/ • F -> ( E ) F.val := E.val val[newtop] = val[top-1] • F -> number F.val := number.lexval /*newtop==top, so nothing to do*/

  35. Desk calculator example • For input 3 * 5 + 4 newline, what happens? • Assume when a terminal’s attribute is shifted when it is. • InputStatesValuesAction • 3*5+4n shift • *5+4n number 3 reduce F->number • reduce T->F • shift • shift • reduce F->number • reduce T->T*F • reduce E->T • shift • shift • reduce F->number • reduce T->F • reduce E->E+T • shift • reduce E->En

  36. L-attributed definitions • S-attributed definitions only allow synthesized attributes. • We saw earlier that inherited attributes are useful. • But we prefer definitions that can be evaluated in one pass. • L-ATTRIBUTED definitions are the set of SDDs whose attributes can be evaluated in a DEPTH-FIRST traversal of the parse tree.

  37. Depth-first traversal • algorithm dfvisit( node n ) { • for each child m of n, in left-to-right order, do { • evaluate the inherited attributes of m • dfvisit( m ) • } • evaluate the synthesized attributes of n • }

  38. L-attributed definitions • If a definition can be evaluated by dfvisit() we say it is L-attributed. • Another way of putting it: a SDD is L-attributed if each INHERITED attribute of Xi on the RHS of a production A -> X1 X2… Xn depends ONLY on: • The attributes of X1, …, Xi-1 (to the LEFT of Xi in the production) • The INHERITED attributes of A. • Since S-attributed definitions have no inherited attributes, they are necessarily L-attributed.

  39. L-attributed definitions • Is the following SDD L-attributed? • ProductionSemantic Rules • A -> L M L.i := l(A.i) • M.i := m(L.s) • A.s := f(M.s) • A -> Q R R.i := r(A.i) • Q.i := q(R.s) • A.s := f(Q.s)

  40. Translation Schemes

  41. Translation schemes • Translation schemes are another way to describe syntax-directed translation. • Translation schemes are closer to a real implementation because the specify when, during the parse, attributes should be computed. • Example, for conversion of INFIX expressions to POSTFIX: • E -> T R • R -> addop T { print ( addop.lexeme ) } | ε • T -> num { print( num.val ) } • This translation scheme will turn 9-5+2 into 95-2+

  42. Turning a SDD into a translation scheme • For a translation scheme to work, it must be the case that an attribute is computed BEFORE it is used. • If the SDD is S-attributed, it is easy to create the translation scheme implementing it: • ProductionSemantic Rule • T -> T1 * F T.val := T1.val x F.val • Translation scheme: • T -> T1 * F { T.val = T1.val * F.val } • That is, we just turn the semantic rule into an action and add at the far right hand side. This DOES NOT WORK for inherited attribs!

  43. Turning a SDD into a translation scheme • With inherited attributes, the translation scheme designer needs to follow three rules: • An inherited attribute for a symbol on the RHS MUST be computed in an action BEFORE the occurrence of the symbol. • An action MUST NOT refer to the synthesized attribute of a symbol to the right of the action. • A synthesized attribute for the LHS nonterminal can ONLY be computed in an action FOLLOWING the symbols for all the attributes it references.

  44. Example • This translation scheme does NOT follow the rules: • S -> A1 A2 { A1.in = 1; A2.in = 2 } • A -> a { print( A.in ) } • If we traverse the parse tree depth first, A1.in has not been set when referred to in the action print( A.in ) • S -> { A1.in = 1 } A1 { A2.in = 2 } A2 • A -> a { print( A.in ) }

  45. Bottom-up evaluation of inherited attributes • The first step is to convert the SDD to a valid translation scheme. • Then a few “tricks” have to be applied to the translation scheme. • It is possible, with the right tricks, to do one-pass bottom-up attribute evaluation for ALL LL(1) grammars and MOST LR(1) grammars, if the SDD is L-attributed. • This means when adding semantic actions to your yacc specifications, you might run into trouble. See section 5.6 of the text!

  46. Beyond Syntax • These questions are part of context-sensitive analysis • Answers depend on values, not parts of speech • Questions & answers involve non-local information • Answers may involve computation • How can we answer these questions? • Use formal methods • Context-sensitive grammars? • Attribute grammars? (attributed grammars?) • Use ad-hoc techniques • Symbol tables • Ad-hoc code (action routines) • In scanning & parsing, formalism won; different story here.

  47. Beyond Syntax • Telling the story • The attribute grammar formalism is important • Succinctly makes many points clear • Sets the stage for actual, ad-hoc practice • The problems with attribute grammars motivate practice • Non-local computation • Need for centralized information • Some folks in the community still argue for attribute grammars • We will cover attribute grammars, then move on to ad-hoc ideas

  48. Attribute Grammars • What is an attribute grammar? • A context-free grammar augmented with a set of rules • Each symbol in the derivation has a set of values, or attributes • The rules specify how to compute a value for each attribute Example grammar Number → Sign List Sign → + | – List → List Bit | Bit Bit → 0 | 1 This grammar describes signed binary numbers We would like to augment it with rules that compute the decimal value of each valid input string

  49. Number Sign List List Bit – List Bit 1 Bit 0 1 Examples Number Sign List Bit – 1

  50. Attribute Grammars • Add rules to compute the decimal value of a signed binary number

More Related