semantic analysis - lecture 9kjleach.eecs.umich.edu/c18/l9.pdf · 4.code generation 5.optimization...

Semantic AnalysisLecture 9

February 7, 2018

Midterm 1

Compiler Stages 12 / 14COOL Programming 10 / 12Regular Languages 26 / 30Context-free Languages 17 / 21Parsing 20 / 23Extra Credit 4 / 6

Average 92

Compiler Construction 2/48

Formal Languages Wrap-up

É You made it!

É Takeaways from lexicalanalysis and parsingÉ Regular languages define

tokensÉ Context-free languages

define parse treesÉ Classes of languages

require different levels ofexpressive power


Compilers Reminder

1. Lexical AnalysisÉ Source code→ Tokens

2. Syntactic AnalysisÉ Tokens→ Abstract Syntax Tree

3. Semantic Analysis (later today)

4. Code Generation

5. Optimization


Compilers Reminder

É Remember, we want to support developers’effort to write softwareÉ They give our compiler source codeÉ Our job is to turn it into a program

É Automatic conversion requires various levels ofanalysisÉ On the front end, we want to extract

structure from the string of source code


Parsing to Extract Structure

É Consider two input strings:É x = 1;É y = 1;

É And what about:É z = 42;É y = 100;

Is there a structural difference between thesestrings?

‘=’

‘x’ ‘1’ ‘;’






‘=’

‘y’ ‘1’ ‘;’






‘=’

‘z’ ‘42’ ‘;’






‘=’

‘y’ ‘100’ ‘;’

Assign→ x = 1; | y = 1;| z = 42; | y = 100;| ...






Assign→ ID = VALUE ;

‘=’

ID VALUE ‘;’



É We want a concise grammarÉ Don’t want to depend on specific values!É S→ ID = VAL ; , not S→ x = 42 ;

É Well, we need an earlier lexical analysis stepÉ Bin lexemes into tokensÉ x, y, z all the same thing: identifiersÉ 1, 42, 100 all the same thing: integer constants


Wrapping Up Formal Languages

É Lexical AnalysisÉ Regular Language = DFA =NFA = Regular

Expression

É Syntactic Analysis / ParsingÉ Context-free Language = Context-free Grammar=Nondeterministic Pushdown Automaton =“Parsing Automaton”


Formal Languages Highlights

É Regular Languages are “easier” to recognizethan CFLs!É Need a stack with CFLs

É As compiler designers, we restrict our choicesof CFLÉ LL and LR are less expressive, but easier to parse

É “Parsing DFA” is kind of a lie! Technically,CFLs are recognized with NPDAsÉ This is not a formal languages course


Parse Tree vs. Abstract Syntax TreeAlmost the sameInput: 6 + ( ( 5 ) )

Parse Tree:

EXP

+

EXP

int

6

EXP

EXP

( )

EXP

( )

int

5Compiler Construction 10/48

Parse Tree vs. Abstract Syntax Tree

Almost the sameInput: 6 + ( ( 5 ) )

Abstract Syntax Tree:

ADD_EXP

int:6 int:5


Parsing HighlightsÉ You should understand that LL and LR are

different restricted subsets of CFLsÉ Trade language expressiveness for parsing ease

É You should know top-down and bottom-upparsingÉ Real parser generators build bottom-up parsers

É We talked about LL(1), recursive descent, andLR(1) parsingÉ There are many other parsing algorithms:

É LALR (lookahead LR)É SLR (simple)É GLR (generalized)É IELR (inadequacy elimination)É Earley


The Front End

É Lexical AnalysisÉ Detects inputs with illegal tokens

É Syntactic AnalysisÉ Detects inputs with ill-formed parse trees

É Semantic AnalysisÉ Last front end phaseÉ Detects more invalid inputs


Intro to Type Checking

É We have just parsed our programÉ It followed the rules of a context-free grammarÉ We know it is a structurally valid program

É Ultimately, programming languages are notcontext-freeÉ Need a rigorous analysis to tell us about semantic

validity of the programÉ Basically, a laundry list of tasks


Intro to Type CheckingÉ We have just parsed our program

É It followed the rules of a context-free grammarÉ We know it is a structurally valid program

É Ultimately, programming languages are notcontext-freeÉ Need a rigorous analysis to tell us about semantic

validity of the programÉ Basically, a laundry list of tasks


Type Checking Summary

Scoping rules match identifier uses withidentifier definitions.A type is a set of values coupled with a setof operations on those values.A type system specifies which operationsare valid for which types.Type checking can be done statically (atcompile time) or dynamically (at run time).


What’s Wrong?

Example 1:1 l e t y : I n t in2 x + 3

Example 2:1 l e t y : S t r i n g <− " abc " in2 y + 3


Semantic Analysis: Why?

É Parsing cannot catch some errorsÉ Some language constructs are not

context-free.É All used variables must have been declared

(scoping)É All methods must be invoked with arguments of

the proper type (i.e. typing)


What does semantic analysis do?Lots of things! In Cool:

É All identifiers are declaredÉ Static typesÉ Inheritance relationshipsÉ Classes defined only onceÉ Methods in a class defined only onceÉ Reserved identifiers are not misusedÉ several others...

The requirements are language-dependent.

É Which of these are checked by Python? C++?


Scope

Scoping rules match identifier useswith identifier declarationsÉ Critical analysis in most

languages (including Cool)


Scope

É The scope of an identifier is the portion of aprogram in which that identifier is accessibleÉ The same identifier may refer to different

things in different parts of the programÉ Different scopes for the same name do not overlap

É An identifier may have restricted scope


Static vs. Dynamic Scope

Most languages have static scopeÉ Scope depends only on the program

text, not the run-time behaviorÉ Cool is statically scoped

A few languages are dynamically scopedÉ LATEX, SNOBOL


Static vs. Dynamic Scope1 int x;23 int main() {4 x = 2;5 f();6 g();7 }8 void f () {9 int x = 3;

10 h();11 }12 void g () {13 int x = 4;14 h();15 }16 void h() {17 printf("%d\n", x);18 }


Static vs. Dynamic Scope1 int x;23 int main() {4 x = 2;5 f();6 g();7 }8 void f () {9 int x = 3;

10 h();11 }12 void g () {13 int x = 4;14 h();15 }16 void h() {17 printf("%d\n", x);18 }

Static scoping output:22

Dynamic scoping output:34


Static Scoping Example

1 let x : Int <- 0 in2 {3 x;4 { let x : Int <- 1 in5 x ;6 };7 x;8 }


Static Scoping Example

9 let x : Int <- 0 in10 {11 x;12 { let x : Int <- 1 in13 x ;14 };15 x;16 }

Uses of x refer to closest enclosing definition.


Scope in Cool

É Cool identifier bindings are introduced byÉ Class declarations (class names)É Method definitions (method names)É Let expressions (object id’s)É Formal parameters (object id’s)É Attribute definitions in a class (object id’s)É Case expressions (object id’s)


Implementing the Most-CloselyNested Rule

Much of semantic analysis can be expressed as arecursive descent of an AST!

É Process an AST node nÉ Process the children of nÉ Finish processing the node n


Implementing ... (2)

Example: the scope of let bindings is one subtree

1 l e t x : I n t <− 0 in expr

x can be used in subtree expr


Symbol TablesRecall: let x : Int <- 0 in expr

Idea:É Before processing expr, add definition of x to

current definitions (override any previousdefinition)É After processing expr, remove definition of x

and restore old definition of x (if any)

A symbol table is a data structure that tracks thecurrent bindings of identifiersÉ Part of PA4É How might we implement this?


Exceptions to Most-closely Nested

Not all kinds of identifiers follow the most-closelynested rule

Class definitions in Cool are globally visiblethroughout all of the program

Implication: class names can be used before it isdefined


Example: Use before define

1 class Foo {2 ... let y : Test in ...3 };4 class Test {5 ...6 };


More Scope in Cool

Attribute names are global within the class in whichthey are defined1 class Foo {2 f() : Int { tm };3 tm : Int <- 0;4 };


More Scope in Cool

Method and attribute names have complex rules

A method need not be defined in the class in whichit is used, but in some parent classÉ that’s inheritance

Methods may also be redefined (overridden)É Which languages allow this? Cool does


Class DefinitionsClass names can be used before being definedWe can’t check this property in one pass :(

SolutionÉ Pass 1: Collect all the class namesÉ Pass 2: Do the checkingÉ ?É Pass 4: Profit!

Semantic analysis requiresmultiple passes


Types

What is a Type?É The notion varies from language to language

ConsensusÉ A set of valuesÉ A set of operations on those values

Classes are one instantiation of the modern notionof type


Why do we need types?

Consider this assembly:

addi, $r1, $r2, $r3

What are the types of r1, r2, and r3?


Types and Operations

Cretain operations are legal or valid for values ofeach type

É It doesn’t make sense to add a function pointerand an integer in CÉ It does make sense to add two integers

É Both are the same in assembly!


Type Systems

A language’s type system specifies whichoperations are valid for which types

The goal of type checking is to ensure that operationsare used with the correct typesÉ Enforces intended interpretation of values,

because nothing else will!É Our last, best hope ... for victorious execution

Type systems provide a concise formalization of thesemantic checking rules


What Can Types Do?

Can detect certain kinds of errors Memory errors:

É Reading from an invalid pointer, etc.

Violation of abstraction boundariesclass FileSystem{

open ( x : String) : File {...

};};

class Client {f( fs : FileSystem ) {

File fdesc <- fs.open("foo")...

}};

The f method can’t see data inside fdesc!


Type Checking Overview

Three kinds of languages:

É Statically typed: All or almost all checking oftypes is done as part of compilation (C, Java,Cool)É Dynamically typed: Almost all checking of

types is done during execution (Python, PHP,Ruby)É Untyped: No type checking (machine code)


The Type Wars

Competing views on static vs. dynamic typing

É Static typing proponents say:É Static checking catches many programming errors at

compile timeÉ Avoids overhead of runtime type checks

É Dynamic typing proponents say:É Static type systems are restrictiveÉ Rapid prototyping is easier in a dynamic type

system


The Type Wars (2)

In practice, most code is written in statically-typedlanguages with an “escape” mechanism.

É Unsafe casts in C, native methods in Java, ...

Dynamic typing (a.k.a. duck typing) is big in thescripting world


Cool Types

In Cool, types areÉ Class namesÉ SELF_TYPE

Technically, there are no native typesÉ Everything is boxed as an object

É Java Integer 6= int

The use declares types for all identifiers

The compiler infers types for expressionsÉ every expression


Type checking and Type Inference

Type Checking is the process of verifyingfully-typed programs

Type Inference is the process of filling in missingtype information

Sometimes used interchangably


Rules of InferenceYou have survived formal languages in specifyingparts ot he compilerÉ Regular expressions (lexer)É Context-free grammars (parser)

We uselogical rules of inferenceas a formalism for type in-ference


Rules of Inference?

Inference rules have the form

If Hypothesis is true, then Conclusion is true

Type checking computes via reasoning:

If E1 and E2 have certain types,then E3 has a certain type

Rules of inference are a compact notation for“If-then” statements


From English to Inference Rules

Start with a simplified system and gradually addfeatures...

Building blocks

É Symbol “∧” is “and”É Symbol “⇒” is “if-then”É x:T is “x has type T”


English to Inference Rules (2)

If e1 has type Int and e2 has type Int,then e1+ e2 has type Int

(e1 has type Int ∧ e2 has type Int)⇒e1+ e2 has type Int

(e1 : Int∧ e2 : Int)⇒ e1+ e2 : Int

This is an inference rule!É e1 : Int∧ e2 : Int are two hypotheses,

e1+ e2 : Int is a conclusion!


Notation for Inference RulesBy tradition, inference rules are written

`Hypothesis1... `Hypothesisn

`Conclusion

Cool type rules have hypotheses and conclusions ofthe form:

` e : T

`means “we can prove that...”


Examples

` i : Int Int

(i is an Integer)

` e1 : Int` e2 : Int` e1+ e2 : Int Add

(the result of adding to Ints is an Int)


Examples (2)

` e1 : Int` e2 : Int` e1+ e2 : Int Add

É These rules give templates describing how totype integers and + expressions...É We can fill in the templates, producing a

complete typing for any expression!

` false : Int` true : Int

` true+ false : IntCompiler Construction 47/48

Example: 1+2

` 1 : Int` 2 : Int` 1+ 2 : Int


semantic analysis - lecture 9kjleach.eecs.umich.edu/c18/l9.pdf · 4.code generation 5.optimization...

Documents