Context Analysis. Mooly Sagiv. html://www.cs.tau.ac.il/~msagiv/courses/wcc11-12.html

Similar documents
Semantic Analysis. Outline. The role of semantic analysis in a compiler. Scope. Types. Where we are. The Compiler so far

The role of semantic analysis in a compiler

Semantic Analysis. Outline. The role of semantic analysis in a compiler. Scope. Types. Where we are. The Compiler Front-End

Types. Type checking. Why Do We Need Type Systems? Types and Operations. What is a type? Consensus

Anatomy of a Compiler. Overview of Semantic Analysis. The Compiler So Far. Why a Separate Semantic Analysis?

The Compiler So Far. Lexical analysis Detects inputs with illegal tokens. Overview of Semantic Analysis

Semantic Analysis. Lecture 9. February 7, 2018

SEMANTIC ANALYSIS TYPES AND DECLARATIONS

The Compiler So Far. CSC 4181 Compiler Construction. Semantic Analysis. Beyond Syntax. Goals of a Semantic Analyzer.

Syntax Errors; Static Semantics

Announcements. Written Assignment 2 due today at 5:00PM. Programming Project 2 due Friday at 11:59PM. Please contact us with questions!

Compiler construction in4020 lecture 5

Introduction to Programming Using Java (98-388)

CSCE 314 Programming Languages. Type System

CSE P 501 Compilers. Static Semantics Hal Perkins Winter /22/ Hal Perkins & UW CSE I-1

Pierce Ch. 3, 8, 11, 15. Type Systems

Compiler construction 2002 week 5

Lecture 7: Type Systems and Symbol Tables. CS 540 George Mason University

Topics Covered Thus Far. CMSC 330: Organization of Programming Languages. Language Features Covered Thus Far. Programming Languages Revisited

FUNCTIONAL AND LOGIC PROGRAMS

CMSC 330: Organization of Programming Languages

Scoping and Type Checking

CS1622. Semantic Analysis. The Compiler So Far. Lecture 15 Semantic Analysis. How to build symbol tables How to use them to find

Types and Type Inference

Type systems. Static typing

Compilers. Type checking. Yannis Smaragdakis, U. Athens (original slides by Sam

The Decaf Language. 1 Lexical considerations

Topics Covered Thus Far CMSC 330: Organization of Programming Languages

Data Types. Every program uses data, either explicitly or implicitly to arrive at a result.

Overview of Semantic Analysis. Lecture 9

Static Semantics. Winter /3/ Hal Perkins & UW CSE I-1

COS 320. Compiling Techniques

Semantic Analysis and Type Checking


Faculty of Electrical Engineering, Mathematics, and Computer Science Delft University of Technology

Names, Scopes, and Bindings II. Hwansoo Han

Announcements. Working on requirements this week Work on design, implementation. Types. Lecture 17 CS 169. Outline. Java Types

CA Compiler Construction

3.Constructors and Destructors. Develop cpp program to implement constructor and destructor.


Static Semantics. Lecture 15. (Notes by P. N. Hilfinger and R. Bodik) 2/29/08 Prof. Hilfinger, CS164 Lecture 15 1

Faculty of Electrical Engineering, Mathematics, and Computer Science Delft University of Technology

Informal Semantics of Data. semantic specification names (identifiers) attributes binding declarations scope rules visibility

Semantic analysis. Semantic analysis. What we ll cover. Type checking. Symbol tables. Symbol table entries

Semantic Processing. Semantic Errors. Semantics - Part 1. Semantics - Part 1

A Fast Review of C Essentials Part I

SE352b: Roadmap. SE352b Software Engineering Design Tools. W3: Programming Paradigms

Type Checking. Outline. General properties of type systems. Types in programming languages. Notation for type rules.

CS 330 Lecture 18. Symbol table. C scope rules. Declarations. Chapter 5 Louden Outline

Type Bindings. Static Type Binding

Visitors. Move functionality

Outline. General properties of type systems. Types in programming languages. Notation for type rules. Common type rules. Logical rules of inference

G Programming Languages Spring 2010 Lecture 6. Robert Grimm, New York University

Short Notes of CS201

The Decaf language 1

COMP 181. Agenda. Midterm topics. Today: type checking. Purpose of types. Type errors. Type checking

Static Checking and Type Systems

CS201 - Introduction to Programming Glossary By

Preface... (vii) CHAPTER 1 INTRODUCTION TO COMPUTERS

Types and Type Inference

NOTE: Answer ANY FOUR of the following 6 sections:

The Structure of a Syntax-Directed Compiler

Compiler construction

CSE450. Translation of Programming Languages. Lecture 11: Semantic Analysis: Types & Type Checking

Lecture 09: Data Abstraction ++ Parsing is the process of translating a sequence of characters (a string) into an abstract syntax tree.

QUIZ. What is wrong with this code that uses default arguments?

Lecture 16: Static Semantics Overview 1

A Short Summary of Javali

5. Semantic Analysis!

COP4020 Programming Languages. Compilers and Interpreters Robert van Engelen & Chris Lacher

Chapter 5. Names, Bindings, and Scopes

CSE 431S Type Checking. Washington University Spring 2013

Compiler construction 2005 lecture 5

Data Types (cont.) Administrative Issues. Academic Dishonesty. How do we detect plagiarism? Strongly Typed Languages. Type System

Motivation for typed languages

Concepts Introduced in Chapter 6

HANDLING NONLOCAL REFERENCES

Programmiersprachen (Programming Languages)

Course Text. Course Description. Course Objectives. StraighterLine Introduction to Programming in C++

5. Semantic Analysis. Mircea Lungu Oscar Nierstrasz

CS143 Handout 03 Summer 2012 June 27, 2012 Decaf Specification

The SPL Programming Language Reference Manual

Acknowledgement. CS Compiler Design. Semantic Processing. Alternatives for semantic processing. Intro to Semantic Analysis. V.

Writing Evaluators MIF08. Laure Gonnord

Context-free grammars (CFG s)

POLYMORPHISM 2 PART Abstract Classes Static and Dynamic Casting Common Programming Errors

LECTURE 3. Compiler Phases

Compiler Theory. (Semantic Analysis and Run-Time Environments)

1 Terminology. 2 Environments and Static Scoping. P. N. Hilfinger. Fall Static Analysis: Scope and Types

POLYMORPHISM 2 PART. Shared Interface. Discussions. Abstract Base Classes. Abstract Base Classes and Pure Virtual Methods EXAMPLE

Outline. Java Models for variables Types and type checking, type safety Interpretation vs. compilation. Reasoning about code. CSCI 2600 Spring

Undergraduate Compilers in a Day

Syntax Analysis/Parsing. Context-free grammars (CFG s) Context-free grammars vs. Regular Expressions. BNF description of PL/0 syntax

CS558 Programming Languages

Compiler Passes. Semantic Analysis. Semantic Analysis/Checking. Symbol Tables. An Example

Chapter 3:: Names, Scopes, and Bindings (cont.)

Intermediate Code Generation

CSE P 501 Compilers. Static Semantics Hal Perkins Spring UW CSE P 501 Spring 2018 I-1

CS /534 Compiler Construction University of Massachusetts Lowell. NOTHING: A Language for Practice Implementation

Decaf Language Reference Manual

Transcription:

Context Analysis Mooly Sagiv html://www.cs.tau.ac.il/~msagiv/courses/wcc11-12.html 1

Short Decaf Program Interface not declared class MyClass implements MyInterface { string myinteger; void dosomething() { int[] x = new string; Type mismatch x[5] = myinteger * y ; y is undefined } Can t multiple integers void dosomething() { Can t redefine functions } int fibonacci(int n) { return dosomething() + fibonacci(n 1); } Can t add void } 2

Outline What is Context (Context) Analysis Why is it needed? Scopes and type checking for imperative languages (Chapter 6) Attribute grammars (Chapter 3) 3

Context Analysis Requirements related to the context in which a construct occurs Context sensitive requirements - cannot be specified using a context free grammar (Context handling) Requires complicated and unnatural context free grammars Guides subsequent phases 4

Basic Compiler Phases Source program (string) Symbol Table Front-End lexical analysis Tokens syntax analysis Abstract syntax tree context analysis Back-End Fin. Assembly 5

Example Context Condition In C break statements can only occur inside switch or loop statements 6

Stm Exp; Partial Grammar for C Stm if (Exp) Stm Stm if (Exp) Stm else Stm Stm while (Exp) do Stm StList StList Stm StList Stm break; Stm {StList } 7

Refined Grammar for C Stm Exp; Stm if (Exp) Stm Stm if (Exp) Stm else Stm Stm while (Exp) do LStm Stm {StList } StList StList Stm StList LStm Exp; LStm if (Exp) LStm LStm if (Exp) LStm else LStm LStm while (Exp) do LStm LStList LStList LStm LStm {LStList } LStm break; LStList 8

A Possible Abstract Syntax for C Stmt Exp (Exp) Stmt Stmt (SeqStmt) Exp Stmt Stmt (IfStmt) Exp Stmt (WhileStmt) (BreakSt) 9

A Possible Abstract Syntax for C package Absyn; abstract public class Absyn { public int pos ;} class Exp extends Absyn { }; class Stmt extends Absyn {} ; class SeqStmt extends Stmt { public Stmt fstst; public Stmt secondst; SeqStmt(Stmt s1, Stmt s2) { fstst = s1; secondst s2 ; } } class IfStmt extends Stmt { public Exp exp; public Stmt thenst; public Stmt elsest; IfStmt(Exp e, Stmt s1, Stmt s2) { exp = e; thenst = s1; elsest s2 ; } } class WhileStmt extends Stmt {public Exp exp; public Stmt body; WhileSt(Exp e; Stmt s) { exp =e ; body = s; } class BreakSt extends Stmt {}; 10

Partial CUP Specification... %% stm::= IF ( exp: e ) stm:s {: RESULT = new IfStm(e, s, null) ; :} IF ( exp: e ) stm:s1 ELSE stm: s2 {: RESULT = new IfStm(e, s1, s2) ; :} WHILE ( exp: e ) stm: s {: RESULT= new WhileStm(e, s); :} { s: stmlist } {: RESULT = s; :} BREAK `;' {: RESULT = new BreakStm(); :} ; stmlist ::= stmlist:s1 stmt:s2 {: RESULT = new SeqStm(s1, s2) ; :} /* empty */ {: RESULT = null ; :} 11

A Context Check (on the abstract syntax tree) static void checkbreak(stmt st) { if (st instanceof SeqSt) { SeqSt seqst = (SeqSt) st; checkbreak(seqst.fstst); checkbreak(seqst.secondst); } else if (st instanceof IfSt) { IfSt ifst = (IfSt) st; checkbreak(ifst.thenst); checkbreak(ifst elsest); } else if (st instanceof WhileSt) ; // skip else if (st instanceof BreakeSt) { System.error.println( Break must be enclosed within a loop. st.pos); } } 12

Syntax Directed Solution parser code {: public int loop_count = 0 ; :} stm : := exp ; IF ( exp ) stm IF ( exp ) stm ELSE stm WHILE ( exp ) m stm {: loop_count--; :} { stmlist } BREAK ; {: if (loop_count == 0) system.error.println( Break must be enclosed within a loop ); :} ; stmlist ::= stmlist st /* empty */ ; m ::= /* empty */ {: loop_count++ ; :} ; 13

Problems with Syntax Directed Translations Grammar specification may be tedious (e.g., to achieve LALR(1)) May need to rewrite the grammar to incorporate different Contexts Modularity is impossible to achieve Some programming languages allow forward declarations (Algol, ML and Java) 14

Example Context Condition: Scope Rules Variables must be defined within scope Dynamic vs. Static Scope rules Cannot be coded using a context free grammar 15

Dynamic vs. Static Scope Rules procedure p; var x: integer procedure q ; begin { q } x end { q }; procedure r ; var x: integer begin { r } q ; end; { r } begin { p } q ; r ; end { p } 16

Example Context Condition In Pascal Types in assignment must be compatible ' 17

Stm id Assign Exp Exp IntConst Exp RealConst Exp Exp + Exp Exp Exp -Exp Exp ( Exp ) Partial Grammar for Pascal 18

Refined Grammar for Pascal Stm RealId Assign RealExp Stm IntExpAssign IntExp Stm RealId Assign IntExp RealExp RealConst RealIntExp RealId RealExp RealExp + RealExp RealExp RealExp + IntExp RealExp IntExp + RealExp RealExp RealExp -RealExp RealExp RealExp -RealExp RealExp RealExp -IntExp RealExp IntExp -RealExp RealExp ( RealExp ) IntExp IntConst IntExp IntId IntExp IntExp + IntExp IntExp IntExp -IntExp IntExp ( IntExp ) 19

Syntax Directed Solution %%... stm : := id:i Assign exp:e {: compatass(lookup(i), e) ; :} ; exp ::= exp:e1 PLUS exp:e2 { : compatop(op.plus, e1, e2); RESULT = optype(op.plus, e1, e2); :} exp:e1 MINUS exp:e2 {: compatop(op.minus, e1, e2); RESULT = optype(op.minus, e1, e2); :} ID: i {: RESULT = lookup(i); :} INCONST {: RESULT = new TyInt() ; :} REALCONST {: RESULT = new TyReal(); :} ( exp: e ) {: RESULT = e ; :} ; 20

Type Checking (Imperative languages) Identify the type of every expression Usually one or two passes over the syntax tree Handle scope rules 21

Types What is a type Varies from language to language Consensus A set of values A set of operations Classes One instantiation of the modern notion of types 22

Why do we need type systems? Consider assembly code add $r1, $r2, $r3 What are the types of $r1, $r2, $r3? 23

Types and Operations Certain operations are legal for values of each type It does not make sense to add a function pointer and an integer in C It does make sense to add two integers But both have the same assembly language implementation! 24

Type Systems A language s type system specifies which operations are valid for which types The goal of type checking is to ensure that operations are used with the correct types Enforces intended interpretation of values because nothing else will! The goal of type inference is to infer a unique type for every valid expression 25

Type Checking Overview Three kinds of languages Statically typed: (Almost) all checking of types is done as part of compilation Context Analysis C, Java, ML Dynamically typed: Almost all checking of types is done as part of program execution Code generation Scheme, Python Untyped No type checking (Machine Code) 26

Type Wars Competing views on static vs. dynamic typing Static typing proponents say: Static checking catches many programming errors Prove properties of your code Avoids the overhead of runtime type checks Dynamic typing proponents say Static type systems are restrictive Rapid prototyping difficult with type systems Complicates the programming language and the compiler Compiler optimizations can hide costs 27

Type Wars (cont.) In practice, most code is written in statically typed languages with escape mechanisms Unsafe casts in C Java union in C It is debatable whether this compromise represents the best or worst of both worlds 28

Soundness of type systems For every expression e, for every value v of e at runtime v val(type(e)) The type may actually describe more values The rules can reject logically correct programs Becomes more complicated with subtyping (inheritance) 29

Issues in Context Analysis Implementation Name Resolution Type Checking Type Equivalence Type Coercions Casts Polymorphism Type Constructors 30

Name Resolution (Identification) Connect applied occurrences of an identifier/operator to its defining occurrence month: Integer RANGE [1..12]; month := 1 while month <> 12 do print_string(month_name[month]); month:= month +1; done; 31

Name Resolution (Identification) Connect applied occurrences of an identifier/operator to its defining occurrence Forward declarations Separate name spaces struct one_int { int i ; } i; i.i = 3; Scope rules 32

A Simple Implementation A separate table per scope/name space Record properties of identifiers Create entries for defining occurrences Search for entries for applied occurrences Create table per scope enter Remove table per scope enter Expensive search 33

Example void roate(double angle) { } void paint(int left, int right) { Shade matt, signal; { Counter right; wrong ; } level 4 3 2 1 wrong signal right paint printf properties P P P P right P matt P left P rotate P signal null null } 0 scope stack P P 34

A Hash-Table Based Implementation A unified hashing table for all occurrences Separate entries for every identifier Ordered lists for different scopes Separate table maps scopes to the entries in the hash Used for ending scopes 35

Example void roate(double angle) { } void paint(int left, int right) { Shade matt, signal; { Counter right; wrong ; } hash table id.info name paint macro decl 1 P name signal macro null decl 3 P 0 P name right macro decl 4 P 2 P null null } 36

Example(cont.) void roate(double angle) { } void paint(int left, int right) { Shade matt, signal; { Counter right; wrong ; } } level 4 3 2 1 0 scope stack id.info( wrong ) id.info( right ) id.info( signal ) id.info( mattt ) right 37 null

Overloading Some programming languages allow to resolve identifiers based on the context 3 + 5 is different than 3.1 + 5.1 Overloading user defined functions PUT(s: STRING) PUT(i: INTEGER) Type checking and name resolution interact May need several passes 38

Type Checking Non-trivial Construct a type table (separate name space) May require several passes 39

Type Equivalence Name equivalence TYPE t1 = ARRAY[Integer] of Integer; TYPE t2 = ARRAY[Integer] of Integer; TYPE t3 = ARRAY[Integer] of Integer; TYPE t4 = t3; Structural equivalence TYPE t5= RECORD {c: Integer ; p: Pointer to t5;} TYPE t6= RECORD {c: Integer ; p: Pointer to t6 ;} TYPE t7 = RECORD {c: Integer ; p : Pointer to RECORD {c: Integer ; p: Pointer to t5;}} 40

Simple Inference The type of an expression depends on the type of the arguments and the required result If e1 has type Integer and e2 has type Integer then the result has type Integer 41

Corner Cases What about power operator 42

Casts and Coercions The compiler may need to insert implicit conversions between types float x = 5; The programmer may need to insert explicit conversions between types 43

L-values vs. R-values Assignment x := exp is compiled into: Compute the address of x Compute the value of exp Store the value of exp into the address of x Generalization R-value Maps program expressions into Context values L-value Maps program expressions into locations Not always defined Java has no small L-values 44

A Simple Example int x = 5; Runtime memory x = x + 1; 17 5 45

A Simple Example int x = 5; lvalue(x)=17, rvalue(x) =5 lvalue(5)=, rvalue(5)=5 x = x + 1; Runtime memory 17 6 lvalue(x)=17, rvalue(x) =5 lvalue(5)=, rvalue(5)=5 46

Partial rules for Lvalue in C Type of e is pointer to T Type of e1 is integer lvalue(e2) exp lvalue rvalue id location(id) content(location(id)) const value(const) *e rvalue(e) content(rvalue(e)) &e2 lvalue(e2) e + e1 rvalue(e)+sizeof(t)*rvalue(e1) 47

Kind Checking Defined L-values in assignments expected found lvalue rvalue lvalue - deref rvalue error - 48

Type Constructors Record types Union Types Arrays 49

Routine Types Usually not considered as data The data can be a pointer to the generated code 50

Dynamic Checks Certain consistencies need to be checked at runtime in general But can be statically checked in many cases Examples Overflow Bad pointers 51

Summary Context analysis requires multiple traversals of the AST Is there a generalization? 52

Attribute Grammars [Knuth 68] Generalize syntax directed translations Every grammar symbol can have several attributes Every production is associated with evaluation rules Context rules The order of evaluation is automatically determined Dependency order Acyclicity Multiple visits of the abstract syntax tree 53

Summary Several ways to enforce Context correctness conditions syntax Regular expressions Context free grammars syntax directed traversals on the abstract syntax tree later compiler phases? Runtime? There are tools that automatically generate Context analyzer from specification (Based on attribute grammars) 62