PROGRAM ANALYSIS & SYNTHESIS

Similar documents
Formal Semantics of Programming Languages

Formal Semantics of Programming Languages

Semantics with Applications 3. More on Operational Semantics

Program Analysis: Lecture 02 Page 1 of 32

Formal Syntax and Semantics of Programming Languages

Formal Syntax and Semantics of Programming Languages

Application: Programming Language Semantics

Note that in this definition, n + m denotes the syntactic expression with three symbols n, +, and m, not to the number that is the sum of n and m.

axiomatic semantics involving logical rules for deriving relations between preconditions and postconditions.

Intro to semantics; Small-step semantics Lecture 1 Tuesday, January 29, 2013

Formal Semantics of Programming Languages

Static Program Analysis

Program Representations

Static Program Analysis

Static analysis and all that

CMSC 330: Organization of Programming Languages. Formal Semantics of a Prog. Lang. Specifying Syntax, Semantics

Harvard School of Engineering and Applied Sciences CS 152: Programming Languages

Exercises on Semantics of Programming Languages

Big-step Operational Semantics (aka Natural Semantics)

Induction and Semantics in Dafny

Chapter 1 Introduction

Principles of Program Analysis: A Sampler of Approaches

Fall Compiler Principles Lecture 5: Intermediate Representation. Roman Manevich Ben-Gurion University of the Negev

Goals: Define the syntax of a simple imperative language Define a semantics using natural deduction 1

Foundations: Syntax, Semantics, and Graphs

Semantics via Syntax. f (4) = if define f (x) =2 x + 55.

Introduction to Denotational Semantics. Class Likes/Dislikes Survey. Dueling Semantics. Denotational Semantics Learning Goals. You re On Jeopardy!

Denotational Semantics

Introduction to Denotational Semantics. Brutus Is An Honorable Man. Class Likes/Dislikes Survey. Dueling Semantics

CMSC 330: Organization of Programming Languages

Lecture 5 - Axiomatic semantics

Principles of Program Analysis. Lecture 1 Harry Xu Spring 2013

CONVENTIONAL EXECUTABLE SEMANTICS. Grigore Rosu CS422 Programming Language Design

CS422 - Programming Language Design

Lectures 20, 21: Axiomatic Semantics

3.7 Denotational Semantics

LECTURE 3. Compiler Phases

CS 6110 S14 Lecture 38 Abstract Interpretation 30 April 2014

CS152: Programming Languages. Lecture 2 Syntax. Dan Grossman Spring 2011

Static Program Analysis

Overview. Probabilistic Programming. Dijkstra s guarded command language: Syntax. Elementary pgcl ingredients. Lecture #4: Probabilistic GCL

No model may be available. Software Abstractions. Recap on Model Checking. Model Checking for SW Verif. More on the big picture. Abst -> MC -> Refine

Program Syntax; Operational Semantics

6. Hoare Logic and Weakest Preconditions

Programming Languages Third Edition

Abstract Interpretation

A Simple Syntax-Directed Translator

COMP 208 Computers in Engineering

Thursday, December 23, The attack model: Static Program Analysis

CS152: Programming Languages. Lecture 5 Pseudo-Denotational Semantics. Dan Grossman Spring 2011

Homework 6: Big- & small-step semantics for LC

A CRASH COURSE IN SEMANTICS

CS 403: Scanning and Parsing

THE COMPILATION PROCESS EXAMPLE OF TOKENS AND ATTRIBUTES

7. Introduction to Denotational Semantics. Oscar Nierstrasz

In Our Last Exciting Episode

Principles of Program Analysis: Data Flow Analysis

Principles of Programming Languages

Overview of Dataflow Languages. Waheed Ahmad

Foundations of Computer Science Spring Mathematical Preliminaries

Operational Semantics 1 / 13

Operational Semantics. One-Slide Summary. Lecture Outline

CONVENTIONAL EXECUTABLE SEMANTICS. Grigore Rosu CS422 Programming Language Semantics

Crafting a Compiler with C (II) Compiler V. S. Interpreter

CSE P 501 Compilers. Parsing & Context-Free Grammars Hal Perkins Winter /15/ Hal Perkins & UW CSE C-1

Using big-step and small-step semantics in Maude to perform declarative debugging

Introduction to Shape and Pointer Analysis

Lecture Programming in C++ PART 1. By Assistant Professor Dr. Ali Kattan

Denotational Semantics. Domain Theory

Chapter 3. The While programming language

Fall Compiler Principles Lecture 6: Intermediate Representation. Roman Manevich Ben-Gurion University of the Negev

CIT Lecture 5 Context-Free Grammars and Parsing 4/2/2003 1

Flow Analysis. Data-flow analysis, Control-flow analysis, Abstract interpretation, AAM

02157 Functional Programming Interpreters for two simple languages including exercises

CS422 - Programming Language Design

CONVENTIONAL EXECUTABLE SEMANTICS. Grigore Rosu CS522 Programming Language Semantics

Proving Properties on Programs From the Coq Tutorial at ITP 2015

COSC252: Programming Languages: Semantic Specification. Jeremy Bolton, PhD Adjunct Professor

CS422 - Programming Language Design

Lexical Analysis. Lexical analysis is the first phase of compilation: The file is converted from ASCII to tokens. It must be fast!

CS558 Programming Languages

Formal semantics of loosely typed languages. Joep Verkoelen Vincent Driessen

Part II. Hoare Logic and Program Verification. Why specify programs? Specification and Verification. Code Verification. Why verify programs?

More on control structures

Type Systems. Today. 1. Organizational Matters. 1. Organizational Matters. Lecture 1 Oct. 20th, 2004 Sebastian Maneth. 1. Organizational Matters

Semantics. There is no single widely acceptable notation or formalism for describing semantics Operational Semantics

Syntax. A. Bellaachia Page: 1

Harvard School of Engineering and Applied Sciences CS 152: Programming Languages

Finite Automata Theory and Formal Languages TMV027/DIT321 LP4 2018

Relation Overriding. Syntax and Semantics. Simple Semantic Domains. Operational Semantics

Symbolic Trajectory Evaluation - A Survey

From IMP to Java. Andreas Lochbihler. parts based on work by Gerwin Klein and Tobias Nipkow ETH Zurich

CS153: Compilers Lecture 17: Control Flow Graph and Data Flow Analysis

CMSC 330: Organization of Programming Languages. Operational Semantics

Data Flow Analysis using Program Graphs

Last class. CS Principles of Programming Languages. Introduction. Outline

Software Engineering using Formal Methods

CVO103: Programming Languages. Lecture 5 Design and Implementation of PLs (1) Expressions

Introduction to Axiomatic Semantics

An Annotated Language

Transcription:

Lecture 02 Structural Operational Semantics (SOS) PROGRAM ANALYSIS & SYNTHESIS EranYahav 1

Previously static analysis over-approximation of program behavior abstract interpretation abstraction, transformers, fixed-point computation examples of program analysis parity abstraction heap abstraction (shape analysis) numerical abstractions examples of program synthesis optimized search in program space program repair as a game SKETCH SMARTEdit 2

Today What is the meaning of a program? semantics structural operational semantics intro to abstract interpretation 3

What is the meaning of a program? int foo(int a ) { if( 0 < a < 5) c = 42 else c = 73; return c; } int a() { printf( a ); return 1; } int b() { printf( b ); return 2; } int c() { printf( c ); return 3; } int sum(int x, int y, int z) { return x+y+z; } void bar() { printf( %d, sum(a(),b(),c()); } 4

Semantics mathematical models of and methods for describing and reasoning about the behavior of programs 5

Why Formal Semantics? implementation-independent definition of a programming language automatically generating interpreters (and some day maybe full fledged compilers) verification and debugging if you don t know what it does, how do you know its incorrect? 6

Different Approaches Denotational Semantics define an input/output relation that assigns meaning to each construct (denotation) Structural Operational Semantics define a transition system, transition relation describes evaluation steps of a program Axiomatic Semantics define the effect of each construct on logical statements about program state (assertions) 7

Denotational Semantics int double1(int x) { int t = 0; t = t + x; t = t + x; return t; } int double2(int x) { int t = 2*x; return t; } λx.2*x λx.2*x 8

Operational Semantics int double1(int x) { int t = 0; t = t + x; t = t + x; return t; } x 2 [t 0, x 2] [t 2, x 2] [t 4, x 2] [t 4, x 2] int double2(int x) { int t = 2*x; return t; } [t 4, x 2] 9

Axiomatic Semantics int double1(int x) { { x = x 0 } int t = 0; { x = x 0 t = 0 } t = t + x; { x = x 0 t = x 0 } t = t + x; { x = x 0 t = 2*x 0 } return t; } int double2(int x) { { x = x 0 } int t = 2*x; { x = x 0 t = 2*x 0 } return t; } 10

Relating Semantics 11

What is the meaning of this program? [y := x] 1 ; [z := 1] 2 ; while [y > 0] 3 ( [z := z * y] 4 ; [y := y 1] 5 ; ) [y := 0] 6 12

what is the meaning of an arithmetic expression? z * y y 1 First: syntax of simple arithmetic expressions For now, assume no variables a ::= n a1 + a2 a1 a2 a1 * a2 (a1) 13

Structural Operational Semantics Defines a transition system (,,T) configurations : snapshots of current state of the program transitions : steps between configurations final configurations T 1 2 = { 1, 2, 3, 4 } 4 3 = { ( 1, 2 ), ( 1, 4 ), ( 2, 3 ) } T = { 3, 4 } 14

Structural Operational Semantics Useful Notations We write when (, ) * denotes the reflexive transitive closure of the relation * when there is a sequence = 0 1 n = for some n 0 15

Big-step vs. Small-step Big-step describes the entire computation is always a terminal configuration Small-step describes a single step of a larger computation need not be a terminal configuration pros/cons to each big-step hard in the presence of concurrency 16

Simple Arithmetic Expressions (big step semantics) [Plus] premises a1 v1 a2 v2 a1 + v1 v side condition where v = v1 + v2 conclusion a v means expression a evaluates to the value v a AExp, v Z 17

Simple Arithmetic Expressions (big step semantics) [Plus] [Minus] [Mult] [Paren] a1 v1 a2 v2 a1 + v1 v a1 v1 a2 v2 a1 - v1 v a1 v1 a2 v2 a1 * v1 v a1 v1 (a1) v where v = v1 + v2 where v = v1 - v2 where v = v1 * v2 [Num] n v if N n = v 18

Simple Arithmetic Expressions (big step semantics) Transition system (,,T) configurations = AExp Z transitions : defined by the rules on the previous slide final configurations T = Z Transitions are syntax directed 19

Derivation Tree show that (2+4)*(4+3) 42 2 2 4 4 4 4 3 3 2 2 4 4 2 + 4 6 4 4 3 3 4 + 3 7 2 + 4 6 (2 + 4) 6 4 + 3 7 (4 + 3) 7 (2+4) 6 (4 + 3) 7 (2+4)*(4 + 3) 42 20

Derivation Tree 2 2 4 4 2 + 4 6 4 4 3 3 4 + 3 7 (2 + 4) 6 (4 + 3) 7 (2+4)*(4 + 3) 42 21

Simple Arithmetic Expressions (small step semantics) [Plus-1] [Plus-2] [Plus-3] a1 a1 a1 + a2 a1 + a2 a2 a2 a1 + a2 a1 + a2 v1 + v2 v where v = v1+ v2 intermediate values intermediate configurations 22

Determinacy We would like the big-step semantics of arithmetic expressions to be deterministic a v1 and a v2 then v1 = v2 induction on the height of the derivation tree ( transition induction ) show that rules for roots are deterministic show that transition rules are deterministic 23

Determinacy Is the small-step semantics of arithmetic expressions deterministic? we want if a v1 and a v2 then v1 = v2 but we have, for example 2 +3 2 + 3 2 + 3 2 + 3 24

Small Step and Big Step small step 0 1 1 2 2 3 big step 0 3 25

The WHILE Language: Syntax Var Lab Op a Op b Op r set of variables set of labels arithmetic operators boolean operators relational operators A AExp B BExp S Stmt arithmetic expressions boolean expressions statements a ::= x n a1 op a a2 b ::= true false not b b1 op b b2 a1 op r a2 S ::= [x := a] lab [skip] lab S1;S2 if [b] lab then S1 else S2 while [b] lab do S (We are going to abuse syntax later for readability) 26

The WHILE Language: Structural Operational Semantics State = Var Z Configuration: <S, > for terminal configuration Transitions: <S, > <S, > <S, > Both the statement that remains to be executed, and the state, can change 27

The WHILE Language: Structural Operational Semantics Transition system (,,T) configurations = (Stmt State) State transitions final configurations T = State 28

Arithmetic Expressions A: AExp (State Z) A x = (x) A n = N n A a1 op a2 = A a1 op A a2 29

Boolean Expressions B: BExp (State { true, false} ) B not b = B b B b1 op b b2 = B b1 op b B b2 B a1 op r a2 = A a1 op r A a2 30

The WHILE Language: Structural Operational Semantics [ass] [skip] <[x := a] lab, > [x A a ] <[skip] lab, > [seq 1 ] <S 1, > <S 1, > <S 1 ; S 2, > < S 1 ; S 2, > [seq 2 ] <S 1, > <S 1 ; S 2, > < S 2, > (Table 2.6 from PPA) 31

The WHILE Language: Structural Operational Semantics [if 1 ] <if [b] lab then S1 else S2, > <S1, > if B b = true [if 2 ] <if [b] lab then S1 else S2, > <S2, > if B b = false [wh 1 ] <while [b] lab do S, > <(S; while [b] lab do S), > if B b = true [wh 1 ] <while [b] lab do S, > if B b = false (Table 2.6 from PPA) 32

Derivation Sequences Finite derivation sequence A sequence <S 0, 0 > n <S i, i > <S i+1, i+1 > n terminal configuration Infinite derivation sequence A sequence <S 0, 0 > <S i, i > <S i+1, i+1 > 33

Termination in small-step semantics while [0 = 0] 1 ( [skip] 2 ; ) < while [0 = 0] 1 ([skip] 2 ), > < [skip] 2 ;while [0 = 0] 1 ([skip] 2 ), > < while [0 = 0] 1 ([skip] 2 ), > < [skip] 2 ;while [0 = 0] 1 ([skip] 2 ), > 34

Termination in small-step semantics We say that S terminates from a start state when there exists a state such that <S, > * 35

Termination in big-step semantics while [0 = 0] 1 ( [skip] 2 ; ) what would be the transition in the big-step semantics for this example? 36

Semantic Equivalence formal semantics enables us to reason about programs and their equivalence S1 and S2 are semantically equivalent when for all and <S1, > * iff <S2, > * We write S1 S2 when S1 and S2 are semantically equivalent 37

Abnormal Termination add a statement abort for aborting execution in the big-step semantics while (0=0) skip; abort big-step semantics does not distinguish between abnormal termination and infinite-loops in the small-step semantics while (0=0) skip; abort but we can distinguish the cases if we look at the transitions <abort, > 0 <abort, > infinite trace of skips 38

Nondeterminism big-step semantics new language construct s1 OR s2 [OR1-BSS] [OR2-BSS] <S 1, > <S 1 OR S 2, > <S 2, > <S 1 OR S 2, > 39

Nondeterminism small-step semantics [OR1-SSS] [OR1-SSS] <S 1 OR S 2, > <S1, > <S 1 OR S 2, > <S2, > 40

Nondeterminism (x = 1) OR while(0=0) skip; big-step semantics suppresses infinite loops small step semantics has the infinite sequence created by picking the while <(x = 1) OR while(0=0) skip;, > <while(0=0) skip;, > 41

What is the meaning of this program? [y := x] 1 ; [z := 1] 2 ; while [y > 0] 3 ( [z := z * y] 4 ; [y := y 1] 5 ; ) [y := 0] 6 now we can answer this question using derivation sequences 42

Example of Derivation Sequence [y := x] 1 ; [z := 1] 2 ; while [y > 0] 3 ( [z := z * y] 4 ; [y := y 1] 5 ; ) [y := 0] 6 < [y := x] 1 ;[z := 1] 2 ;while [y > 0] 3 ([z := z * y] 4 ;[y := y 1] 5 ;)[y := 0] 6,{ x 42, y 0, z 0 } > < [z := 1] 2 ;while [y > 0] 3 ([z := z * y] 4 ;[y := y 1] 5 ;)[y := 0] 6,{ x 42, y 42, z 0 } > < while [y > 0] 3 ([z := z * y] 4 ;[y := y 1] 5 ;)[y := 0] 6,{ x 42, y 42, z 1 } > < ([z := z * y] 4 ;[y := y 1] 5 ;);while [y > 0] 3 ([z := z * y] 4 ;[y := y 1] 5 ;)[y := 0] 6,{ x 42, y 42, z 1 }> 43

Traces < [y := x] 1 ;[z := 1] 2 ;while [y > 0] 3 ([z := z * y] 4 ;[y := y 1] 5 ;)[y := 0] 6,{ x 42, y 0, z 0 } > < [z := 1] 2 ;while [y > 0] 3 ([z := z * y] 4 ;[y := y 1] 5 ;)[y := 0] 6,{ x 42, y 42, z 0 } > < while [y > 0] 3 ([z := z * y] 4 ;[y := y 1] 5 ;)[y := 0] 6,{ x 42, y 42, z 1 } > < ([z := z * y] 4 ;[y := y 1] 5 ;);while [y > 0] 3 ([z := z * y] 4 ;[y := y 1] 5 ;)[y := 0] 6,{ x 42, y 42, z 1 }> [y := x] 1 < [y := x] 1 ;[z := 1] 2 ;while [y > 0] 3 ([z := z * y] 4 ;[y := y 1] 5 ;)[y := 0] 6,{ x 42, y 0, z 0 } > [z := 1] 2 < [z := 1] 2 ;while [y > 0] 3 ([z := z * y] 4 ;[y := y 1] 5 ;)[y := 0] 6,{ x 42, y 42, z 0 } > [y > 0] 3 < while [y > 0] 3 ([z := z * y] 4 ;[y := y 1] 5 ;)[y := 0] 6,{ x 42, y 42, z 1 } > < ([z := z * y] 4 ;[y := y 1] 5 ;);while [y > 0] 3 ([z := z * y] 4 ;[y := y 1] 5 ;)[y := 0] 6,{ x 42, y 42, z 1 }> 44

Traces [y := x] 1 < [y := x] 1 ;[z := 1] 2 ;while [y > 0] 3 ([z := z * y] 4 ;[y := y 1] 5 ;)[y := 0] 6,{ x 42, y 0, z 0 } > [z := 1] 2 < [z := 1] 2 ;while [y > 0] 3 ([z := z * y] 4 ;[y := y 1] 5 ;)[y := 0] 6,{ x 42, y 42, z 0 } > [y > 0] 3 < while [y > 0] 3 ([z := z * y] 4 ;[y := y 1] 5 ;)[y := 0] 6,{ x 42, y 42, z 1 } > < ([z := z * y] 4 ;[y := y 1] 5 ;);while [y > 0] 3 ([z := z * y] 4 ;[y := y 1] 5 ;)[y := 0] 6,{ x 42, y 42, z 1 }> [y := x] 1 < 1,{ x 42, y 0, z 0 } > [z := 1] 2 < 2,{ x 42, y 42, z 0 } > [y > 0] 3 < 3,{ x 42, y 42, z 1 } > < 4,{ x 42, y 42, z 1 }> 45

Traces [y := x] 1 < 1,{ x 42, y 0, z 0 } > [z := 1] 2 < 2,{ x 42, y 42, z 0 } > [y > 0] 3 < 3,{ x 42, y 42, z 1 } > < 4,{ x 42, y 42, z 1 }> 46

Trace Semantics [y := x] 1 ; [z := 1] 2 ; while [y > 0] 3 ( [z := z * y] 4 ; [y := y 1] 5 ; ) [y := 0] 6 [y := x] 1 [z := 1] 2 < 1,{ x 42, y 0, z 0 } > < 2,{ x 42, y 42, z 0 } > [y > 0] 3 < 3,{ x 42, y 42, z 1 } > < 4,{ x 42, y 42, z 1 }> [y := x] 1 [z := 1] 2 < 1,{ x 73, y 0, z 0 } > < 2,{ x 73, y 73, z 0 } > [y > 0] 3 < 3,{ x 73, y 73, z 1 } > < 4,{ x 73, y 73, z 1 }> In the beginning, there was the trace semantics note that input (x) can be anything clearly, the trace semantics is not computable 47

Abstract Interpretation abstract abstract state S abstract state concrete C S C C set of states set of states 48

Dataflow Analysis 1: y := x; 2: z := 1; 3: while y > 0 { 4: z := z * y; 5: y := y 1 } 6: y := 0 { (x,?), (y,?), (z,?) } { (x,?), (y,1), (z,?) } { (x,?), (y,1), (z,2) } { (x,?), (y,1), (z,2) } { (x,?), (y,?), (z,4) } { (x,?), (y,5), (z,4) } { (x,?), (y,1), (z,2) } { (x,?), (y,?), (z,?) } Reaching Definitions The assignment lab: var := exp reaches lab if there is an execution where var was last assigned at lab (adapted from Nielson, Nielson & Hankin) 49

Dataflow Analysis 1: y := x; 2: z := 1; 3: while y > 0 { 4: z := z * y; 5: y := y 1 } 6: y := 0 { (x,?), (y,?), (z,?) } { (x,?), (y,1), (z,?) } { (x,?), (y,1), (z,2), (y,5), (z,4) } { (x,?), (y,1), (z,2), (y,5), (z,4) } { (x,?), (y,?), (z,4), (y,5) } { (x,?), (y,5), (z,4) } { (x,?), (y,1), (z,2), (y,5), (z,4) } { (x,?), (y,6), (z,2), (z,4) } Reaching Definitions The assignment lab: var := exp reaches lab if there is an execution where var was last assigned at lab (adapted from Nielson, Nielson & Hankin) 50

Dataflow Analysis Build control-flow graph Assign transfer functions Compute fixed point 51

Control-Flow Graph 1: y := x; 2: z := 1; 3: while y > 0 { 4: z := z * y; 5: y := y 1 } 6: y := 0 1: y:=x 2: z:=1 3: y > 0 4: z=z*y 6: y:=0 5: y=y-1 52

Transfer Functions 1: y:=x out(1) = in(1) \ { (y,l) l Lab } U { (y,1) } 2: z:=1 out(2) = in(2) \ { (z,l) l Lab } U { (z,2) } 3: y > 0 out(3) = in(3) in(1) = { (x,?), (y,?), (z,?) } in(2) = out(1) in(3) = out(2) U out(5) in(4) = out(3) in(5) = out(4) in(6) = out(3) 4: z=z*y 6: y:=0 out(6) = in(6) \ { (y,l) l Lab } U { (y,6) } out(4) = in(4) \ { (z,l) l Lab } U { (z,4) } 5: y=y-1 out(5) = in(5) \ { (y,l) l Lab } U { (y,5) } 53

System of Equations in(1) = { (x,?), (y,?), (z,?) } in(2) = out(1) in(3) = out(2) U out(5) in(4) = out(3) in(5) = out(4) In(6) = out(3) out(1) = in(1) \ { (y,l) l Lab } U { (y,1) } out(2) = in(2) \ { (z,l) l Lab } U { (z,2) } out(3) = in(3) out(4) = in(4) \ { (z,l) l Lab } U { (z,4) } out(5) = in(5) \ { (y,l) l Lab } U { (y,5) } out(6) = in(6) \ { (y,l) l Lab } U { (y,6) } F: ( (Var x Lab) ) 12 ( (Var x Lab) ) 12 54

Least Fixed Point We will see later why it exists For now, mostly informally F: ( (Var x Lab) ) 12 ( (Var x Lab) ) 12 RD RD when i: RD(i) RD (i) F is monotone: RD RD implies that F(RD) F(RD ) RD = (,,, ) F(RD ), F(F(RD ), F(F(F(RD )), F n (RD ) F n (RD ) F(F(RD )) F(RD ) RD F n+1 (RD ) = F n (RD ) 55

Things that Should Trouble You How did we get the transfer functions? How do we know these transfer functions are safe (conservative)? How do we know that these transfer functions are optimal? 56

References Transitions and Trees / Huttel Principles of Program Analysis / Nielson, Nielson, and Hankin 57