编译原理 第六章 Semantic Analysis

本书以 编译原理及实践 为textbook

Chapter Six. Semantic Analysis

attributes and attribute grammers
$X.a$: the value of $a$ associated to $X$
$X$ is a grammar symbol and $a$ is an attribute associated to $X$
syntax-directed semantics: attributes are associated directly with the grammar symbols of the language.
Given attributes $a_1,a_2,\dots ,a_k$, for each grammar rule $X_0\to X_1{X}_2\dots X_n$ ( $X_0$ is a nonterminal ), the values of the attributes Xi.aj of each grammar symbol $X_i$ are related to the values of the attributes of the other symbols in the rule.
An attribute grammar for attributes $a_1,a_2,\dots ,a_k$ is the collection of all attribute equations or semantic rules of the following form, for all the grammar rules of the language.
$X_i.a_j=f_{ij}(X_0.a_1,\dots ,X_0.a_k,X_1.a_1,\dots ,X_1.a_k,\dots ,X_n.a_1,\dots X_n.a_k)$
$f_{ij}$ is a mathematical function of its arguments

dependency graph
dependency graph of the string (sentence) is the union of the dependency graphs of the grammar rule choices representing each node(nonleaf) of the parse tree of the string.
$X_i.a_j=f_{ij}(X_0.a_1,\dots ,X_0.a_k,X_1.a_1,\dots ,X_1.a_k,\dots ,X_n.a_1,\dots X_n.a_k)$
An edge from each node $X_m.a_k$ to $X_i.a_j$ the node expressing the dependency of $X_i.a_j$ on $X_m.a_k$

Parse tree method: construction of the dependency graph is based on the specific parse tree at compile time, add complexity, and need circularity detective.
Rule based method: fix an order for attribute evaluation at compiler construction time. It depends on an analysis of the attribute equations, or semantic rules.

Classification of the attributes:

1. synthesized attributes
2. inherited attributes

Synthesized attributes:
An attribute is synthesized:

1. if all its dependencies point from child to parent in the parse tree.
2. given a grammar rule $A\to X_1{X}_2\dots X_n$, the only associated attribute equation with an A.a on the left-hand side is of the form:$A.a=f(X_1.a_1,\dots X_1.a_k,\dots X_n.a_1,\dots X_n.a_k)$

S-attributed grammar:
An attribute grammar in which all the attributes are synthesized

The attribute values of an S-attributed grammar can be computed by a single bottom-up, or post-order, traversal of the parse or syntax tree.

Procedure PostEval (T : treenode);
Begin 
	For each child C of T do
	     PostEval(C);
	Compute all synthesized attributes of T;
End

An attribute that is not synthesized is called an inherited attribute.

inherited attributes : computed by a preorder traversal , or combined preorder/inorder traversal of the parse or syntax tree, represented by the following pseudocode:

Procedure PreEval(T: treenode);
Begin
	For each child C of T do
		Compute all inherited attributes of C;
		PreEval(C);
End;

Inherited attributes:
be computed in preorder, often be treated as parameters of the call.
Synthesized attributes:
be computed in postorder, often be treated as returned values of the call.

The computation of attributes during parsing:

1. Attributes that computed successfully at the same time as the parsing stage depends on the power and properties of the parsing method employed.
2. All the major parsing methods process the input program from left to right (LL, or LR) .
3. require the attribute be capable of evaluation by a left-to-right traversal of the parse tree (synthesized attributes will always be OK).

L-attributed:
An attribute grammar for attribute $a_1,\dots ,a_k$ is L-attributed if , for each inherited attribute aj and each grammar rule:$X_0\to X_1{X}_2\dots X_n$
The associated equations for aj are all of the form:
$X_i.a_j=f_{ij}(X_0.a_1,...,X_0.a_k,X_1.a_1,...,X_1.a_k,.X_{i-1}.a_1,...,X_{i-1}.a_k)$

Given an L-attributed grammar in which the inherited attributes do not depend on the synthesized attributes:

1. Top-down parser: a recursive-descent parser can evaluate all the attributes by turning the inherited attributes into parameters and synthesized attributes into returned values.
2. Bottom-up parser: LR parsers are suited to handling primarily synthesized attributes, but are difficult for inherited attributes.

computing synthesized attributes during LR parsing
Value stack: store synthesized attributes, be manipulated in parallel with the parsing stack.

inheriting a previously computed synthesized attributes during LR parsing
an action associated to a nonterminal in the right-hand side of a rule can make use of synthesized attributes of the symbols to the left of it in the rule.
The question can be settled through a ε–production as follows:
A → B D C B → . . . { c o m p u t e r B . s } D → ϵ s a v e d i = f ( v a l s t a c k [ t o p ] ) C → . . . { n o w   s a v e d i   i s   a v a i l a b l e } \begin{matrix} A\rightarrow BDC\\ B\rightarrow ... &\{computer B.s\}\\ D\rightarrow \epsilon &saved_{i}= f(valstack[top]) \\ C\rightarrow ...& \{now\ saved_{i}\ is\ available\} \end{matrix} A→BDCB→...D→ϵC→...​{computerB.s}savedi​=f(valstack[top]){now savedi​ is available}​

Problems:

1. Require the programmer to directly access the value stack during a parse
   this may be risky in automatically generated parsers.
2. only works if the position of the previously computed attribute is predictable from the grammar.

the best technique for dealing with inherited attributes in LR parsing:

1. use external data structures (symbol table or nonlocal variables) to hold inherited attribute values.
2. add $ϵ-$ p roduction or embedded actions as in Yacc (may add parsing conflicts) to allow for changes to these data structures to occur at appropriate moments.

modifications to the grammar that do not change the legal strings of the language (make the computation of attributes simpler or more complex.)
The properties of attributes depend heavily on the structure of the grammar.

Given an attribute grammar , all inherited attributes can be changed into synthesized attributes by suitable modification of the grammar, without changing the language of the grammar.(from Knuth [1968]).

Semantic checks refer to properties of identifiers in the program – their scope or type
Need an environment to store the information about identifiers = symbol table
Each entry in the symbol table contains the name of an identifier, additional information: its kind, its type, if it is constant,

The structure of the symbol table:

1. linear list
2. various search tree structures
3. hash tables

hash collision:

1. Collision resolution
2. (perfer) separate chaining

The process of the hash function:

1. converts a character string (the identifier name) into a nonnegative integer.
2. These integers are combined in some way to form a single integer.
3. The result integer is scaled to the range 0…size-1.

The algorithm of the hash function:

1. one simple algorithm : ignore many of the characters and to add together only the value of the first few, or the first, middle, and last, characters.
2. Another simple method : add up the values of all the characters.
3. one good solution : repeatedly use a constant number $\alpha$ as a multiplying factor when adding in the value of the next character.

four basic kinds of declarations:

1. constant declarations,
2. type declarations,
3. variable declarations
4. procedure/function declarations.

Declarations
The strategies:

1. use one symbol table to hold the names from all the different kinds of declarations.
2. use a different symbol table for each kind of declaration.
3. associate separate symbol tables with different regions of a program and link them together according to the semantic rules of the language.

two rules:

1. declaration before use
2. the most closely nested rule for block structure

Another solution: building a new symbol table for each scope and to link the tables from inner to outer scopes together

Interaction of same-level declarations algorithm:

1. Lookup before each insert.
2. Determine by some mechanism whether any preexisting declarations with the same name are at the same level or not.

different declaration:

1. sequential declaration:
   each declaration is added to the symbol table as it is processed.
2. collateral declaration:
   1. declarations not be added immediately to the existing
      symbol table
   2. accumulated in a new table(or temporary structure)
   3. then added to the existing table after all declarations have
      been processed.
3. recursive declaration:
   declaration may refer to themselves or each other.

type checking

Two general groups about language:

1. permit the direct use of recursion in type declarations.
2. do not permit direct use of recursion in type declarations.

Classification of type equivalence:

1. Structural equivalence
2. Name equivalence
3. Declaration equivalence

Structural equivalence:
two types are the same if and only if they have the same structure.
two types are the same if and only if they have syntax trees that are identical in structure.

two arrays are equivalent: the same size and component type.
two records are equivalent: the same components with the same names and in the same order.
different choices:
The size of the array can be ignored
The components of a structure or union can be in a different order.

Name equivalence:
two type expressions are equivalent if and only if they are either the same simple type or are the same type name.
type expressions can be allowed in variable declarations or subexpressions of type expressions.
a type expression may have no explicit name given to it, a compiler will have to generate an internal name for the type expression that is different from any other names.

Declaration equivalence:
weaker version of name equivalence

Overloading: the same operator name is used for two different operations
type conversion and coercion:
allow arithmetric expressions of mixed type.
There are two approaches a language can take to such conversions:

1. Require the programmer supply a conversion function (Modula-2)
2. The type checker supply the conversion automatically. (C ) ( coercion)

Polymorphic typing