Semantic Analysis

Content influenced by many excellent references, see References slide for acknowledgements.
An Overview of Compilation
source program target program

lexical analyzer code generator

symbol table

syntax analyzer error handler code optimizer

intermediate code
semantic analyzer
generator
Beyond Scanning and Parsing
• A compiler must do more than just recognize whether a sentence
belongs to a programming language grammar
• An input program can be grammatically correct but may contain other errors
that prevent compilation
• Lexer and parser cannot catch all program errors
• Some language features cannot be modeled using context-free
grammar (CFG)
• Whether a variable has been declared before use?
• Parameter types and numbers match in the declaration and use of a function
• Types match on both sides of an assignment
 Questions That Compiler Needs to Answer
• Has a variable been declared?
• What is the type and size of a variable?
• Is the variable scalar or an array?
• Is an array access A[i][j][k] consistent with the declaration?
• Does the name “x” correspond to a variable or a function?
Questions • If x is a function, how many arguments does it take?
• What kind of value, if any, does a function x return?
• Are all invocations of a function consistent with the
declaration?
• Track inheritance relationship
• Ensure that classes and its methods are not multiply defined
Semantic Analysis: Static Semantics
• Finding answers to these questions is part of the semantic analysis
phasen
• For example, ensure variable are declared before their uses and check that
each expression has a correct type
• These are static semantics of languages
Checking Dynamic Semantics
• Dynamic semantics of languages int dot_prod(int x[], int y[]) {
need to be checked at run time int d, i;
• Whether an overflow will occur d = 0;
during an arithmetic operation? for (i=0; i<10; i++)
• Whether array bounds will be d += x[i]*y[i];
exceeded during execution?
return d;
• Whether recursion will exceed stack
limits? }

• Compilers can generate code to main() {

check dynamic semantics int p; int a[10], b[10];
p = dot_prod(a,b);
}
How does a compiler answer these
questions?
• Use formal methods like context-sensitive grammars

• Use ad-hoc techniques using symbol table

• Static semantics of PL can be specified using attribute grammars

• Attribute grammars are extensions of context-free grammars
Attribute Grammar Framework
Attribute Grammar Framework

• Two notations for associating semantic rules with

productions
• Syntax directed definition
•high level specifications
•hides implementation details
•explicit order of evaluation is not specified
• Syntax directed translation or Translation scheme
•indicate order in which semantic rules are to be evaluated
•allow some implementation details to be shown

10
 SDD and SDT Scheme
SDD:

SDT:
F → id { print id.val } // semantic action

SDD: Specifies the values of attributes by associating semantic

rules with the productions.
SDT: Embeds program fragments (also called semantic actions)
within production bodies.
The position of the action defines the order in which the
action is executed (in the middle of production or end).
SDD is easier to read; easy for specification.
SDT scheme can be more efficient; easy for implementation.
SDD Vs. SDT Scheme – Infix to Postfix translation
Attribute Grammar Framework
• Conceptually both:
– parse input token stream
– build parse tree
– traverse the parse tree to evaluate the semantic rules at the
parse tree nodes
• Evaluation may:
– save information in the symbol table
– issue error messages
– generate code
– perform any other activity

13
Syntax-Directed Definition
• A syntax-directed definition (SDD) is a context-free grammar with
rules and attributes
• A SDD specifies the values of attributes by associating semantic rules with the
grammar productions

Production Semantic Rule

𝐸 → 𝐸1 + 𝑇 𝐸. 𝑐𝑜𝑑𝑒 = 𝐸1 . 𝑐𝑜𝑑𝑒||𝑇. 𝑐𝑜𝑑𝑒||" + "
Syntax-Directed Definition
• Generalization of CFG where each grammar symbol has an associated
set of attributes
• Let 𝐺 = (𝑇, 𝑁𝑇, 𝑆, 𝑃) be a CFG and let 𝑉 = 𝑇 𝖴 𝑁𝑇
• Every symbol 𝑋 ∈ 𝑉 is associated with a set of attributes (for e.g., denoted by
𝑋. 𝑎 and 𝑋. 𝑏)
• Each attribute takes values from a specified domain (finite or infinite), which
is its type
• Typical domains of attributes are, integers, reals, characters, strings, booleans, and
structures
• New domains can be constructed from given domains by mathematical
operations such as cross product and map
• Values of attributes are computed by semantic rules
 Type of Attributes
• Attributes fall into two classes: Synthesized
and Inherited
• Value of a synthesized attribute is computed from
the values of children nodes
▪ Attribute value for LHS of a rule comes from attributes of RHS
• Value of an inherited attribute is computed
from the sibling and parent nodes
• Attribute value for a symbol on RHS of a rule comes from
attributes of LHS and RHS symbols
 17

Example

A → XYZW
Parent: A, Child: X, Y, Z, W
If parent is taking any value from child(s), then it is
synthesized.
If parent is giving any value or siblings are giving
any value, then it is inherited.
 SDD: Synthesized Attributes
• SDD evaluates expressions terminated by an endmarker n.
• In the SDD, each of the non-terminals has a single synthesized attribute, called
val.
• The terminal digit has a synthesized attribute lexval, which is an integer value
returned by the lexical analyzer.
 SDD: Synthesized Attributes
• Production 2: E → E1 + T, has one rule, which computes the val attribute for the
head E as the sum of the values at E1 and T.
• At any parse-tree node N labeled E, the value of val for E is the sum of the values
of val at the children of node N labeled E and T.
• An SDD that involves only synthesized attributes is called S-attributed; the SDD
below has this property.
Inherited Attributes

Production Semantic Rules

𝑇 ′ . 𝑖𝑛ℎ = 𝐹. 𝑣𝑎𝑙
𝑇→ 𝐹𝑇 ′
𝑇. 𝑣𝑎𝑙 = 𝑇 ′ . 𝑠𝑦𝑛
𝑇 ′ . 𝑖𝑛ℎ = 𝑇 ′ . 𝑖𝑛ℎ × 𝐹. 𝑣𝑎𝑙
𝑇 ′ →∗ 𝐹𝑇 ′ 1
1
𝑇 ′ . 𝑠𝑦𝑛 = 𝑇 ′ . 𝑠𝑦𝑛
1
𝑇′ → 𝜖 𝑇 ′ . 𝑠𝑦𝑛 = 𝑇 ′ . 𝑖𝑛ℎ
𝐹 → digit 𝐹. 𝑣𝑎𝑙 = digit. 𝑙𝑒𝑥𝑣𝑎𝑙
 Evaluating an SDD at the Nodes of a Parse Tree

• In what order do we evaluate attributes?

• If all attributes are synthesized (last Example/table), then we must evaluate the val
attributes at all of the children of a node before we can evaluate the val attribute at the
node itself.
• For SDD’s with both inherited and synthesized attributes, there is no guarantee that there
is even one order in which to evaluate attributes at nodes.
• Consider non-terminals A and B, with synthesized and inherited attribute A.s and B.i,
respectively, along with the production and rules.
Evaluating an SDD at the Nodes of a Parse Tree

• These rules are circular.

• Synthesized: Children and itself
• Inherited: Parent, itself and siblings
• It is impossible to evaluate either A.s
at a node N or B.i at the child of N without
first evaluating the other.
Types of SDDs
• Arbitrary SDDs can have cycles
• Cycles need to be avoided
• Can no longer meaningfully proceed with evaluation
• Expensive to detect
• Two types of SDDs guarantee no cycles
• S-attributed and L-attributed
S-Attributed Definition
• An SDD that involves only synthesized attributes is called S-attributed
definition
• Each rule computes an attribute for the head nonterminal from attributes
taken from the body of the production

• Semantic rules in a S-attributed definition can be evaluated by a

bottom-up or postorder traversal of the parse tree
• An S-attributed SDD can be implemented naturally in conjunction with an LR
parser
Example SDD
Production Semantic Rules
𝐿→𝐸$ 𝐿. 𝑣𝑎𝑙 = 𝐸. 𝑣𝑎𝑙
𝐸 → 𝐸1 + 𝑇 𝐸. 𝑣𝑎𝑙 = 𝐸1 . 𝑣𝑎𝑙 + 𝑇. 𝑣𝑎𝑙
𝐸→𝑇 𝐸. 𝑣𝑎𝑙 = 𝑇. 𝑣𝑎𝑙
𝑇 → 𝑇1 ∗ 𝐹 𝑇. 𝑣𝑎𝑙 = 𝑇1 . 𝑣𝑎𝑙 × 𝐹. 𝑣𝑎𝑙
𝑇→𝐹 𝑇. 𝑣𝑎𝑙 = 𝐹. 𝑣𝑎𝑙
𝐹 → (𝐸) 𝐹. 𝑣𝑎𝑙 = 𝐸. 𝑣𝑎𝑙
𝐹 → digit 𝐹. 𝑣𝑎𝑙 = digit. 𝑙𝑒𝑥𝑣𝑎𝑙
L-Attributed Definitions
• Each attribute must be either
I. Synthesized
II. Suppose 𝐴 → 𝑋1 𝑋2 … 𝑋𝑛 and Production Semantic Rules
𝑋𝑖 . 𝑎 is an inherited attribute. 𝑇→ 𝐹𝑇 ′
𝑇 ′ . 𝑖𝑛ℎ = 𝐹. 𝑣𝑎𝑙
𝑋 . 𝑎 can be computed using 𝑇. 𝑣𝑎𝑙 = 𝑇 ′ . 𝑠𝑦𝑛
𝑇 ′ . 𝑖𝑛ℎ = 𝑇 ′ . 𝑖𝑛ℎ × 𝐹. 𝑣𝑎𝑙
a) Only inherited attributes from 𝐴, 𝑇 ′ →∗ 𝐹𝑇 ′ 1
1
or 𝑇 ′ . 𝑠𝑦𝑛 = 𝑇 ′ . 𝑠𝑦𝑛
1
b) Either inherited or synthesized 𝑇′ → 𝜖 𝑇 ′ . 𝑠𝑦𝑛 = 𝑇 ′ . 𝑖𝑛ℎ
attributes associated with
𝑋1 , … , 𝑋𝑖 −1 located to the left of 𝑋𝑖 𝐹 → digit 𝐹. 𝑣𝑎𝑙 = digit. 𝑙𝑒𝑥𝑣𝑎𝑙
or
c) Inherited or synthesized attributes
associated with 𝑋𝑖 such that there
are no cycles
L-Attributed Definitions or L-Attributed Definitions?
L-Attributed Definitions or L-Attributed Definitions?

A -> LM is not S-attributed SDT, but it is L-attributed SDT.

A -> QR is not S-attributed SDT, but it is not L-attributed SDT (because Q.i =
q(R.s) – Here, left sibling is not satisfied.
Are these SDDs S- or L-attributed?
Production Semantic Rules
𝐴. 𝑎 = 𝐵. 𝑏1
𝐴 → 𝐵𝐶
𝐵. 𝑏2 = 𝑓(𝐴. 𝑎, 𝐶. 𝑐)

Production Semantic Rules

𝐵. 𝑖 = 𝑓1 (𝐴. 𝑖)
𝐴 → 𝐵𝐶 𝐶. 𝑖 = 𝑓2 (𝐵. 𝑠)
𝐴. 𝑠 = 𝑓3 (𝐶. 𝑠)

Production Semantic Rules

𝐶. 𝑖 = 𝑓4 (𝐴. 𝑖)
𝐴 → 𝐵𝐶 𝐵. 𝑖 = 𝑓5 (𝐶. 𝑠)
𝐴. 𝑠 = 𝑓6 (𝐵. 𝑠)
S-Attributed and L-Attributed Definitions

Every S-attributed grammar is also a L-attributed

grammar

All L-attributed grammars are not S-attributed

Dependency Graph
• The dependencies among the nodes are depicted by a directed graph
called dependency graph
• If an attribute 𝑏 depends on an attribute 𝑐 then the semantic rule for
𝑏 must be evaluated after the semantic rule for 𝑐
Dependency Graph
• Suppose 𝐴. 𝑎 = 𝑓 𝑋. 𝑥, 𝑌. 𝑦 is a semantic rule for 𝐴 → 𝑋𝑌
𝐴 𝐴. 𝑎
Parse tree Dependency
graph
𝑋 𝑌 𝑋. 𝑥 𝑌. 𝑦

• Suppose 𝑋. 𝑥 = 𝑓(𝐴. 𝑎, 𝑌. 𝑦) is a semantic rule for 𝐴 → 𝑋𝑌

𝐴 𝐴. 𝑎

𝑋 𝑌 𝑋. 𝑥 𝑌. 𝑦
 Example
• Whenever following production is used in a parse tree
E→ E1 + E2 E.val = E1.val + E2.val
we create a dependency graph

E.val

E1.val E2.val

33
Annotated Parse Tree
• A parse tree showing the
value(s) of its attribute(s) is
called an annotated parse
tree
Example Attribute Grammar
Draw Parse tree for 3 * 5 + 4 n
 Parse tree for 3 * 5 + 4 n

E n

E + T

T F

T * digit
F

F digit

digit
Annotated Parse Tree
• A parse tree showing the
value(s) of its attribute(s) is
called an annotated parse
tree
 Annotated Parse tree for 3 * 4 + 5 n

L Print 17

Val=17 E $

Val=12 E + T Val=5

Val=12 T F Val=5

Val=3 T * F Val=4 id

Val=3 F id

digit 21
Postfix Notation
• Postfix notation for an expression 𝐸 is defined inductively
• If 𝐸 is a variable or constant, then postfix notation is 𝐸
• If 𝐸 = 𝐸1op𝐸2 where op is any binary operator, then the postfix notation is
𝐸1′ 𝐸2′ op, where 𝐸1′ and 𝐸2′ are postfix notations for 𝐸1 and 𝐸2 respectively
• If 𝐸 = (𝐸1), then postfix notation for 𝐸1 is the notation for 𝐸
SDD for Infix to Postfix Translation
Production Semantic Rules
𝑒𝑥𝑝𝑟 → 𝑒𝑥𝑝𝑟1 + 𝑡𝑒𝑟𝑚 𝑒𝑥𝑝𝑟. 𝑐𝑜𝑑𝑒 = 𝑒𝑥𝑝𝑟1 . 𝑐𝑜𝑑𝑒||𝑡𝑒𝑟𝑚. 𝑐𝑜𝑑𝑒||"+"
𝑒𝑥𝑝𝑟 → 𝑒𝑥𝑝𝑟1 − 𝑡𝑒𝑟𝑚 𝑒𝑥𝑝𝑟. 𝑐𝑜𝑑𝑒 = 𝑒𝑥𝑝𝑟1 . 𝑐𝑜𝑑𝑒||𝑡𝑒𝑟𝑚. 𝑐𝑜𝑑𝑒||" − "
𝑒𝑥𝑝𝑟 → 𝑡𝑒𝑟𝑚 𝑒𝑥𝑝𝑟. 𝑐𝑜𝑑𝑒 = 𝑡𝑒𝑟𝑚. 𝑐𝑜𝑑𝑒
𝑡𝑒𝑟𝑚. 𝑐𝑜𝑑𝑒 = "0"
𝑡𝑒𝑟𝑚. 𝑐𝑜𝑑𝑒 = "1"
𝑡𝑒𝑟𝑚 → 0 1 … | 9
…
𝑡𝑒𝑟𝑚. 𝑐𝑜𝑑𝑒 = "9"
 𝑒𝑥𝑝𝑟 Parse
9-5+2
Tree
𝑒𝑥𝑝𝑟 "+" 𝑡𝑒𝑟𝑚

"2"
𝑒𝑥𝑝𝑟 "−" 𝑡𝑒𝑟𝑚

𝑡𝑒𝑟𝑚 "5"

"9"
Annotated Parse Tree
𝑒𝑥𝑝𝑟. 𝑐𝑜𝑑𝑒 = "95 − 2 + "

𝑒𝑥𝑝𝑟. 𝑐𝑜𝑑𝑒 = "95 − " "+" 𝑡𝑒𝑟𝑚. 𝑐𝑜𝑑𝑒 = "2"

"2"
𝑒𝑥𝑝𝑟. 𝑐𝑜𝑑𝑒 = "9" "−" 𝑡𝑒𝑟𝑚. 𝑐𝑜𝑑𝑒 = "5"

𝑡𝑒𝑟𝑚. 𝑐𝑜𝑑𝑒 = "9" "5"

"9"
Parse Tree and Annotated Parse Tree for 3 ∗ 5
 Parse Tree and Annotated Parse Tree for 3 ∗ 5
𝑇

𝐹 𝑇′

digit

∗ 𝐹 𝑇1′

digit 𝜖
 Parse Tree and Annotated Parse Tree for 3 ∗ 5
𝑇 𝑇. 𝑣𝑎𝑙 = 15

𝐹 𝑇′ 𝐹. 𝑣𝑎𝑙 = 3 𝑇 ′ . 𝑖𝑛ℎ = 3
𝑇 ′ . 𝑠𝑦𝑛 = 15

digit digit. 𝑙𝑒𝑥𝑣𝑎𝑙 = 3

∗ 𝐹 𝑇1′ 𝐹. 𝑣𝑎𝑙 = 5 𝑇1′ . 𝑖𝑛ℎ = 15

∗
𝑇1′ . 𝑠𝑦𝑛 = 15

digit 𝜖
digit. 𝑙𝑒𝑥𝑣𝑎𝑙 = 5 𝜖
 Parse Tree and Annotated Parse Tree for 3 ∗ 5
𝑇 𝑇. 𝑣𝑎𝑙 = 15

𝐹 𝑇′ 𝐹. 𝑣𝑎𝑙 = 3 𝑇 ′ . 𝑖𝑛ℎ = 3
𝑇 ′ . 𝑠𝑦𝑛 = 15

digit digit. 𝑙𝑒𝑥𝑣𝑎𝑙 = 3

∗ 𝐹 𝑇1′ 𝐹. 𝑣𝑎𝑙 = 5 𝑇1′ . 𝑖𝑛ℎ = 15

∗
𝑇1′ . 𝑠𝑦𝑛 = 15

digit 𝜖
digit. 𝑙𝑒𝑥𝑣𝑎𝑙 = 5 𝜖
Another Example Parse Tree for “float 𝑥, 𝑦, 𝑧”?

Production Semantic Rules

𝐷 → 𝑇𝐿 𝐿. 𝑖𝑛 = 𝑇. 𝑡𝑦𝑝𝑒
𝑇 → float 𝑇. 𝑡𝑦𝑝𝑒 = float
𝑇 → int 𝑇. 𝑡𝑦𝑝𝑒 = int
𝐿 → 𝐿1 , id 𝐿1 . 𝑖𝑛 = 𝐿. 𝑖𝑛; 𝑎𝑑𝑑𝑡𝑦𝑝𝑒(id. 𝑒𝑛𝑡𝑟𝑦, 𝐿. 𝑖𝑛)
𝐿 → id 𝑎𝑑𝑑𝑡𝑦𝑝𝑒(id. 𝑒𝑛𝑡𝑟𝑦, 𝐿. 𝑖𝑛)

𝑎𝑑𝑑𝑡𝑦𝑝𝑒() installs 𝐿. 𝑖𝑛 as the type of the symbol table object

pointed to by id. 𝑒𝑛𝑡𝑟𝑦
Another Example Parse Tree for “float 𝑥, 𝑦, 𝑧”

Production Semantic Rules 𝐷

𝐷 → 𝑇𝐿 𝐿. 𝑖𝑛 = 𝑇. 𝑡𝑦𝑝𝑒
𝑇 → float 𝑇. 𝑡𝑦𝑝𝑒 = float 𝑇 𝐿
𝑇 → int 𝑇. 𝑡𝑦𝑝𝑒 = int
𝐿 → 𝐿1 , id 𝐿1 . 𝑖𝑛 = 𝐿. 𝑖𝑛; 𝑎𝑑𝑑𝑡𝑦𝑝𝑒(id. 𝑒𝑛𝑡𝑟𝑦, 𝐿. 𝑖𝑛)
float 𝐿 , id
𝐿 → id 𝑎𝑑𝑑𝑡𝑦𝑝𝑒(id. 𝑒𝑛𝑡𝑟𝑦, 𝐿. 𝑖𝑛)

𝐿 , id
𝑎𝑑𝑑𝑡𝑦𝑝𝑒() installs 𝐿. 𝑖𝑛 as the type of the symbol table object
pointed to by id. 𝑒𝑛𝑡𝑟𝑦
id
Annotated Parse Tree

𝑇.type=float 𝐿.in= float

float 𝐿.in = float , id

𝐿.in= float , id

id
Abstract Syntax Tree (AST)
• Condensed form of a parse tree used for representing language
constructs
• ASTs do not check for string membership in the language for a grammar
• ASTs represent relationships between language constructs, do not bother
with derivations
if−then−else

𝑆 → if 𝑃 then 𝑆1else 𝑆2

P 𝑆1 𝑆2

• Parse trees are also called concrete syntax trees

Parse Tree and Abstract Syntax Tree
Parse Tree Abstract Syntax Tree

𝐸𝑥𝑝𝑟 +

𝐸𝑥𝑝𝑟 + 𝑇𝑒𝑟𝑚
− name

𝐸𝑥𝑝𝑟 − 𝑇𝑒𝑟𝑚 𝐹𝑎𝑐𝑡𝑜𝑟

name name
𝑇𝑒𝑟𝑚 𝐹𝑎𝑐𝑡𝑜𝑟 name

𝐹𝑎𝑐𝑡𝑜𝑟 name

name
Creating an AST
• Following sequence of function calls create an AST for 𝑎 − 4 + 𝑐

1. 𝑝1 = new 𝐿𝑒𝑎𝑓(id, 𝑒𝑛𝑡𝑟𝑦𝑎) +

2. 𝑝2 = new 𝐿𝑒𝑎𝑓(num, 4)
3. 𝑝3 = new 𝑁𝑜𝑑𝑒(“ − ”, 𝑝1, 𝑝2)
4. 𝑝4 = new 𝐿𝑒𝑎𝑓(id, 𝑒𝑛𝑡𝑟𝑦𝑐) − id
5. 𝑝5 = new 𝑁𝑜𝑑𝑒(“ + ”, 𝑝3, 𝑝4)
entry for 𝑐

id num 4

entry for 𝑎
S-Attributed Definition for Constructing
Syntax Trees

Production Semantic Rules

𝐸 → 𝐸1 + 𝑇 𝐸. 𝑛𝑜𝑑𝑒 = 𝐧𝐞𝐰 𝑁𝑜𝑑𝑒(" + ", 𝐸1 . 𝑛𝑜𝑑𝑒, 𝑇. 𝑛𝑜𝑑𝑒)
𝐸 → 𝐸1 − 𝑇 𝐸. 𝑛𝑜𝑑𝑒 = 𝐧𝐞𝐰 𝑁𝑜𝑑𝑒(" − ", 𝐸1 . 𝑛𝑜𝑑𝑒, 𝑇. 𝑛𝑜𝑑𝑒)
𝐸→𝑇 𝐸. 𝑛𝑜𝑑𝑒 = 𝑇. 𝑛𝑜𝑑𝑒
𝑇 → (𝐸) 𝑇. 𝑛𝑜𝑑𝑒 = 𝐸. 𝑛𝑜𝑑𝑒
𝑇 → id 𝑇. 𝑛𝑜𝑑𝑒 = 𝐧𝐞𝐰 𝐿𝑒𝑎𝑓(id, id. 𝑒𝑛𝑡𝑟𝑦)
𝑇 → num 𝑇. 𝑛𝑜𝑑𝑒 = 𝐧𝐞𝐰 𝐿𝑒𝑎𝑓(num, num. 𝑣𝑎𝑙)
Construction of AST for 𝑎 − 4 + 𝑐

Draw Parse Tree for 𝑎 − 4 + 𝑐

Construction of AST for 𝑎 − 4 + 𝑐 AST edge

Parse Tree edge

𝐸 𝑛𝑜𝑑𝑒

𝐸 𝑛𝑜𝑑𝑒 + 𝑇 𝑛𝑜𝑑𝑒

𝐸 𝑛𝑜𝑑𝑒 − 𝑇 𝑛𝑜𝑑𝑒 id
+
num
𝑇 𝑛𝑜𝑑𝑒 id
−

id entry for 𝑐

id
i num 4
d
entry for 𝑎
Bottom-up Evaluation of S-Attributed
Definitions
Input … … 𝑤 $
• Suppose 𝐴 → 𝑋𝑌𝑍, and
semantic rule is 𝐴. 𝑎 =
𝑓(𝑋. 𝑥, 𝑌. 𝑦, 𝑍. 𝑧)
𝑍. 𝑧 𝑍
LR Parsing
Program
• Can be computed during 𝑌. 𝑦 𝑌
bottom-up parsing
• On reduction, value of new 𝑋. 𝑥 𝑋
synthesized attribute 𝐴. 𝑎 is
computed from the attributes $ $
on the stack
• Extend stack to hold values Value State
stack stack
Example S-Attributed Definition
Bottom-up Evaluation of S-Attributed Definitions
Bottom-up Evaluation of S-Attributed Definitions
Value State Input Action
$ $ 3 ∗ 5 + 4$ Shift
$3 $digit ∗ 5 + 4$ Reduce by 𝐹 → digit
$3 $𝐹 ∗ 5 + 4$ Reduce by 𝑇 → 𝐹
$3 $𝑇 ∗ 5 + 4$ Shift
$3 $𝑇 ∗ 5 + 4$ Shift
$3 5 $𝑇 ∗ digit +4$ Reduce by 𝐹 → digit
$3 5 $𝑇 ∗ 𝐹 +4$ Reduce by 𝑇 → 𝑇 ∗ 𝐹
$15 $𝑇 +4$ Reduce by 𝐸 → 𝑇
$15 $𝐸 +4$ Shift
$15 $𝐸 + 4$ Shift
$15 4 $𝐸 + digit $ Reduce by 𝐹 → digit
$15 4 $𝐸 + 𝐹 $ Reduce by 𝑇 → 𝐹
$15 4 $𝐸 + 𝑇 $ Reduce by 𝐸 → 𝐸 + 𝑇
$19 $𝐸 $ …
SDT for Infix to Postfix Translation
SDD SDT
Production Semantic Rules Production Semantic Rules
𝑒𝑥𝑝𝑟 𝑒𝑥𝑝𝑟. 𝑐𝑜𝑑𝑒 = 𝑒𝑥𝑝𝑟 → 𝑒𝑥𝑝𝑟1 + 𝑡𝑒𝑟𝑚 { 𝑝𝑟𝑖𝑛𝑡 " + " }
→ 𝑒𝑥𝑝𝑟1 + 𝑡𝑒𝑟𝑚 𝑒𝑥𝑝𝑟1 . 𝑐𝑜𝑑𝑒||𝑡𝑒𝑟𝑚. 𝑐𝑜𝑑𝑒||" + "
𝑒𝑥𝑝𝑟 → 𝑒𝑥𝑝𝑟1 − 𝑡𝑒𝑟𝑚 { 𝑝𝑟𝑖𝑛𝑡 " − " }
𝑒𝑥𝑝𝑟 𝑒𝑥𝑝𝑟. 𝑐𝑜𝑑𝑒 =
→ 𝑒𝑥𝑝𝑟1 − 𝑡𝑒𝑟𝑚 𝑒𝑥𝑝𝑟1 . 𝑐𝑜𝑑𝑒||𝑡𝑒𝑟𝑚. 𝑐𝑜𝑑𝑒||" − " 𝑒𝑥𝑝𝑟 → 𝑡𝑒𝑟𝑚
𝑒𝑥𝑝𝑟 → 𝑡𝑒𝑟𝑚 𝑒𝑥𝑝𝑟. 𝑐𝑜𝑑𝑒 = 𝑡𝑒𝑟𝑚. 𝑐𝑜𝑑𝑒 { 𝑝𝑟𝑖𝑛𝑡("0") }
𝑡𝑒𝑟𝑚. 𝑐𝑜𝑑𝑒 = "0"
{ 𝑝𝑟𝑖𝑛𝑡("1") }
𝑡𝑒𝑟𝑚 → 0 1 … | 9
𝑡𝑒𝑟𝑚. 𝑐𝑜𝑑𝑒 = "1" …
𝑡𝑒𝑟𝑚 → 0 1 … | 9 { 𝑝𝑟𝑖𝑛𝑡("9") }
…
𝑡𝑒𝑟𝑚. 𝑐𝑜𝑑𝑒 = "9"
SDT Actions
𝑒𝑥𝑝𝑟

𝑒𝑥𝑝𝑟 "+" 𝑡𝑒𝑟𝑚 { 𝑝𝑟𝑖𝑛𝑡 "+" }

𝑒𝑥𝑝𝑟 "−" 𝑡𝑒𝑟𝑚 { 𝑝𝑟𝑖𝑛𝑡 " − " } "2" { 𝑝𝑟𝑖𝑛𝑡 "2" }

𝑡𝑒𝑟𝑚 "5" { 𝑝𝑟𝑖𝑛𝑡 "5" }

"9" { 𝑝𝑟𝑖𝑛𝑡 "9" }

 SDT for Infix to Postfix Translation
Remove left recursion :
SDT
Production Semantic Rules
𝑒𝑥𝑝𝑟 → 𝑒𝑥𝑝𝑟1 + 𝑡𝑒𝑟𝑚 { 𝑝𝑟𝑖𝑛𝑡 " + " }
𝑒𝑥𝑝𝑟 → 𝑒𝑥𝑝𝑟1 − 𝑡𝑒𝑟𝑚 { 𝑝𝑟𝑖𝑛𝑡 " − " }
𝑒𝑥𝑝𝑟 → 𝑡𝑒𝑟𝑚
{ 𝑝𝑟𝑖𝑛𝑡("0") }
{ 𝑝𝑟𝑖𝑛𝑡("1") }
𝑡𝑒𝑟𝑚 → 0 1 … | 9
…
{ 𝑝𝑟𝑖𝑛𝑡("9") }

Generate Annotated parse tree for 2+5+3

 SDT for Infix to Postfix Translation
Remove left recursion :
SDT
Production Semantic Rules expr→ term P
𝑒𝑥𝑝𝑟 → 𝑒𝑥𝑝𝑟1 + 𝑡𝑒𝑟𝑚 { 𝑝𝑟𝑖𝑛𝑡 " + " } P → + 𝑡𝑒𝑟𝑚 { 𝑝𝑟𝑖𝑛𝑡 " + " }P
P → epsilon
𝑒𝑥𝑝𝑟 → 𝑒𝑥𝑝𝑟1 − 𝑡𝑒𝑟𝑚 { 𝑝𝑟𝑖𝑛𝑡 " − " }
𝑡𝑒𝑟𝑚 → 0 1 …|9
𝑒𝑥𝑝𝑟 → 𝑡𝑒𝑟𝑚 { 𝑝𝑟𝑖𝑛𝑡("0") }
{ 𝑝𝑟𝑖𝑛𝑡("0") } { 𝑝𝑟𝑖𝑛𝑡("1") }
{ 𝑝𝑟𝑖𝑛𝑡("1") } …
𝑡𝑒𝑟𝑚 → 0 1 … | 9 { 𝑝𝑟𝑖𝑛𝑡("9") }
…
{ 𝑝𝑟𝑖𝑛𝑡("9") }

Generate Annotated parse tree for 2+5+3

 SDT for Infix to Postfix Translation

SDT
Production Semantic Rules
𝑒𝑥𝑝𝑟 → 𝑒𝑥𝑝𝑟1 + 𝑡𝑒𝑟𝑚 { 𝑝𝑟𝑖𝑛𝑡 " + " }
𝑒𝑥𝑝𝑟 → 𝑒𝑥𝑝𝑟1 − 𝑡𝑒𝑟𝑚 { 𝑝𝑟𝑖𝑛𝑡 " − " }
𝑒𝑥𝑝𝑟 → 𝑡𝑒𝑟𝑚
{ 𝑝𝑟𝑖𝑛𝑡("0") }
{ 𝑝𝑟𝑖𝑛𝑡("1") }
𝑡𝑒𝑟𝑚 → 0 1 … | 9
…
{ 𝑝𝑟𝑖𝑛𝑡("9") }

Generate Annotated parse tree for 2+6+1 26+1+

Bottom up evaluation of inherited attributes
Bottom up evaluation of inherited attributes
Bottom up evaluation of inherited attributes
References
• A. Aho et al. Compilers: Principles, Techniques, and Tools, 2nd edition, Chapter 2.3, Chapter 5.
• K. Cooper and L. Torczon. Engineering a Compiler, 2nd edition, Chapter 4.
• M. Scott. Programming Language Pragmatics, 4th edition, Chapter 4.