Upload
others
View
2
Download
0
Embed Size (px)
Citation preview
Deductive Verification of Programs
Laura Kovacs
TU Wien
1 / 141
Outline
Introduction
Small Imperative Language IMP
2 / 141
Computer Systems and Correctness
I Suppose we design a (complex) software system.
I We have requirements on how the system should function, forexample safety, security, availability, etc.
I How can one ensure that the system satisfies theserequirements?
Deductive verification of programs
3 / 141
Computer Systems and Correctness
I Suppose we design a (complex) software system.
I We have requirements on how the system should function, forexample safety, security, availability, etc.
I How can one ensure that the system satisfies theserequirements?
Deductive verification of programs
4 / 141
Computer Systems and Correctness
I Suppose we design a (complex) software system.
I We have requirements on how the system should function, forexample safety, security, availability, etc.
I How can one ensure that the system satisfies theserequirements?
Deductive verification of programs
5 / 141
Computer Systems and Correctness
I Suppose we design a (complex) software system.
I We have requirements on how the system should function, forexample safety, security, availability, etc.
I How can one ensure that the system satisfies theserequirements?
Deductive verification of programs
6 / 141
A Small ExampleConsider the following program:
/* Returns a new array of integers of a givenlength initialised by a non-zero value */
int* allocateArray(int length){int i;int* array;array = malloc(sizeof(int)*length);
for (i = 0;i <= length;i++)array[i] = 0;
return array;}
Is this program correct?
7 / 141
A Small ExampleConsider the following program:
/* Returns a new array of integers of a givenlength initialised by a non-zero value */
int* allocateArray(int length){int i;int* array;array = malloc(sizeof(int)*length);
for (i = 0;i <= length;i++)array[i] = 0;
return array;}
Is this program correct?
8 / 141
A Small ExampleConsider the following program:
/* Returns a new array of integers of a givenlength initialised by a non-zero value */
int* allocateArray(int length){int i;int* array;array = malloc(sizeof(int)*length);
for (i = 0;i <= length;i++)array[i] = 0;
return array;}
Is this program correct?Hardly: it writes into memory that has not been allocated.
9 / 141
A Small ExampleConsider the following program:
/* Returns a new array of integers of a givenlength initialised by a non-zero value */
int* allocateArray(int length){int i;int* array;array = malloc(sizeof(int)*length);
for (i = 0;i < length;i++)array[i] = 0;
return array;}
Is this program correct?
10 / 141
A Small ExampleConsider the following program:
/* Returns a new array of integers of a givenlength initialised by a non-zero value */
int* allocateArray(int length){int i;int* array;array = malloc(sizeof(int)*length); // may return 0!
for (i = 0;i < length;i++)array[i] = 0;
return array;}
Is this program correct?No: it may write to the null address.
11 / 141
A Small ExampleConsider the following program:
/* Returns a new array of integers of a givenlength initialised by a non-zero value */
int* allocateArray(int length){int i;int* array;array = malloc(sizeof(int)*length);if (!array) return 0;for (i = 0;i < length;i++)
array[i] = 0;return array;
}
Is this program correct?
12 / 141
A Small ExampleConsider the following program:
/* Returns a new array of integers of a givenlength initialised by a non-zero value */
int* allocateArray(int length){int i;int* array;array = malloc(sizeof(int)*length);if (!array) return 0;for (i = 0;i < length;i++)
array[i] = 0;return array;
}
Is this program correct?No: it initialises the array by zeros
13 / 141
A Small ExampleConsider the following program:
/* Returns a new array of integers of a givenlength initialised by a non-zero value */
int* allocateArray(int length){int i;int* array;array = malloc(sizeof(int)*length);if (!array) return 0;for (i = 0;i < length;i++)
array[i] = 0;return array;
}
Is this program correct?
We discussed correctness of a program without defining what itmeans.
14 / 141
A Small ExampleConsider the following program:
/* Returns a new array of integers of a givenlength initialised by a non-zero value */
int* allocateArray(int length){int i;int* array;array = malloc(sizeof(int)*length);if (!array) return 0;for (i = 0;i < length;i++)
array[i] = 0;return array;
}
Is this program correct?
We discussed correctness of a program without defining what itmeans.So what is correctness?
15 / 141
Notes
I We could spot the first two errors without knowing anything aboutthe intended meaning of the program. But we had to understandthe meaning of the program in general and some specificproperties of programming in C-like languages (or otherprogramming languages).
I To understand the last “error” we had to know something aboutthe intended behaviour of the program.
16 / 141
Notes
I We could spot the first two errors without knowing anything aboutthe intended meaning of the program. But we had to understandthe meaning of the program in general and some specificproperties of programming in C-like languages (or otherprogramming languages).
I To understand the last “error” we had to know something aboutthe intended behaviour of the program.
17 / 141
How to establish correctness
I Consider the program/system as amathematical object.Build a formal model of the system.
I Find a formal language forexpressing intended properties.
I Prove that the system modelsatisfies the specification.
State Transition Systemsand its Semantics
First-Order Logic (FOL),
SAT/SMT/FOL Formulas,
Deductive verification,
18 / 141
How to establish correctness
I Consider the program/system as amathematical object.Build a formal model of the system.
I Find a formal language forexpressing intended properties.
I Prove that the system modelsatisfies the specification.
State Transition Systemsand its Semantics
First-Order Logic (FOL),
SAT/SMT/FOL Formulas,
Deductive verification,
19 / 141
How to establish correctness
I Consider the program/system as amathematical object.Build a formal model of the system.
I Find a formal language forexpressing intended properties.
I Prove that the system modelsatisfies the specification.
State Transition Systemsand its Semantics
First-Order Logic (FOL),
SAT/SMT/FOL Formulas,
Deductive verification,
20 / 141
How to establish correctness
I Consider the program/system as amathematical object.Build a formal model of the system.
I Find a formal language forexpressing intended properties.
This language must have asemantics that explains what arepossible interpretations of thesentences of the formal language.
The semantics is normally based onnotions is true, is false, satisfies.
I Prove that the system modelsatisfies the specification.
State Transition Systemsand its Semantics
First-Order Logic (FOL),
SAT/SMT/FOL Formulas,
Deductive verification,
21 / 141
How to establish correctness
I Consider the program/system as amathematical object.Build a formal model of the system.
I Find a formal language forexpressing intended properties.
This language must have asemantics that explains what arepossible interpretations of thesentences of the formal language.
The semantics is normally based onnotions is true, is false, satisfies.
I Prove that the system modelsatisfies the specification.
State Transition Systemsand its Semantics
First-Order Logic (FOL),Temporal Logic
SAT/SMT/FOL Formulas,
Deductive verification,
22 / 141
How to establish correctness
I Consider the program/system as amathematical object.Build a formal model of the system.
I Find a formal language forexpressing intended properties.
I Write a specification, that is,intended properties of the system inthis language.
I Prove that the system modelsatisfies the specification.
State Transition Systemsand its Semantics
First-Order Logic (FOL),Temporal Logic
SAT/SMT/FOL Formulas,
Deductive verification,
23 / 141
How to establish correctness
I Consider the program/system as amathematical object.Build a formal model of the system.
I Find a formal language forexpressing intended properties.
I Write a specification, that is,intended properties of the system inthis language.
I Prove that the system modelsatisfies the specification.
State Transition Systemsand its Semantics
First-Order Logic (FOL),Temporal Logic
SAT/SMT/FOL Formulas,Temporal Logic Formulas
Deductive verification,
24 / 141
How to establish correctness
I Consider the program/system as amathematical object.Build a formal model of the system.
I Find a formal language forexpressing intended properties.
I Write a specification, that is,intended properties of the system inthis language.
I Prove that the system modelsatisfies the specification.
State Transition Systemsand its Semantics
First-Order Logic (FOL),Temporal Logic
SAT/SMT/FOL Formulas,Temporal Logic Formulas
Deductive verification,
25 / 141
How to establish correctness
I Consider the program/system as amathematical object.Build a formal model of the system.
I Find a formal language forexpressing intended properties.
I Write a specification, that is,intended properties of the system inthis language.
I Prove that the system modelsatisfies the specification.
State Transition Systemsand its Semantics
First-Order Logic (FOL),Temporal Logic
SAT/SMT/FOL Formulas,Temporal Logic Formulas
Deductive verification,model checking
26 / 141
Deductive Verification of Programs
I Consider the program/system as amathematical object.Build a formal model of the system.
I Find a formal language forexpressing intended properties.
I Write a specification, that is,intended properties of the system inthis language.
I Prove that the system modelsatisfies the specification.
State Transition Systemsand its Semantics
First-Order Logic (FOL),
SAT/SMT/FOL Formulas,
Deductive verification,
27 / 141
Deductive Verification of Programs
Program
Specification
Deductiveverifier
Correct
Incorrect
I Statically reason about program behavior without executing theprogram: consider all possible program executions under all inputs
I Examples of specifications: absence of arithmetic overflow, arrayis sorted, program terminates . . .
28 / 141
Deductive Verification of Programs
Program
Specification
Deductiveverifier
Correct
Incorrect
I Statically reason about program behavior without executing theprogram: consider all possible program executions under all inputs
I Examples of specifications: absence of arithmetic overflow, arrayis sorted, program terminates . . .
29 / 141
Deductive Verification of Programs
Program
Terminates
Specification
Deductiveverifier
Correct
Incorrect
30 / 141
Deductive Verification of Programs
Program
Terminates
Specification
Deductiveverifier
Correct
Incorrect
The Halting Problem
: UndecidableI A problem is undecidable if there does not exist a
that can solve itAlan Turing, 1936
31 / 141
Deductive Verification of Programs
Program
Terminates
Specification
Deductiveverifier
Correct
Incorrect
The Halting Problem: UndecidableI A problem is undecidable if there does not exist a
Turing machine that can solve itAlan Turing, 1936
32 / 141
Deductive Verification of Programs
Program
Terminates
Specification
Deductiveverifier
Correct
Incorrect
The Halting Problem: UndecidableI A problem is undecidable if there does not exist a
C/Java program that can solve itAlan Turing, 1936
33 / 141
Deductive Verification of Programs
Program
Terminates
Specification
Deductiveverifier
Correct
Incorrect
The Halting Problem: UndecidableI A problem is undecidable if there does not exist a
computer program that can solve itAlan Turing, 1936
34 / 141
Deductive Verification of Programs
Program
Terminates
Specification
Deductiveverifier
Correct
Incorrect
Undecidable: Verifier cannot exist
I There is no computer program that can alwaysdecide whether a computer program satisfies anon-trivial specification (Rice Theorem)
Alan Turing, 1936
35 / 141
Deductive Verification of Programs
Program
Terminates
Specification
Deductiveverifier
Correct
Incorrect
Undecidable: Verifier cannot existI There is no computer program that can always
decide whether a computer program satisfies anon-trivial specification (Rice Theorem)
Alan Turing, 1936
36 / 141
Deductive Verification – Living with Undecidability
I Programs that “sometimes” diverge
I Limit programs that can be analyzedI finite-state, loop-free, bounded arithmetic, . . .
I Partial/unsound verification approachesI Testing: analyze program executions on a fixed input set
37 / 141
Deductive Verification – Living with Undecidability
I Programs that “sometimes” diverge
I Limit programs that can be analyzedI finite-state, loop-free, bounded arithmetic, . . .
I Partial/unsound verification approachesI Testing: analyze program executions on a fixed input set
38 / 141
Deductive Verification – Living with Undecidability
I Programs that “sometimes” diverge
I Limit programs that can be analyzedI finite-state, loop-free, bounded arithmetic, . . .
I Partial/unsound verification approachesI Testing: analyze program executions on a fixed input set
39 / 141
Deductive Verification – Living with Undecidability
I Programs that “sometimes” diverge
I Limit programs that can be analyzedI finite-state, loop-free, bounded arithmetic, . . .
I Partial/unsound verification approachesI Testing: analyze program executions on a fixed input set
if (x-100<=0)if (y-100<=0)if (x+y-200==0)
crash();
If x and y are 32-bit integers, whatis the probability of a crash?
I 1/264
Testing is hard!
40 / 141
Deductive Verification – Living with Undecidability
I Programs that “sometimes” diverge
I Limit programs that can be analyzedI finite-state, loop-free, bounded arithmetic, . . .
I Partial/unsound verification approachesI Testing: analyze program executions on a fixed input set
if (x-100<=0)if (y-100<=0)if (x+y-200==0)
crash();
If x and y are 32-bit integers, whatis the probability of a crash?
I 1/264
Testing is hard!
41 / 141
Deductive Verification – Living with Undecidability
I Programs that “sometimes” diverge
I Limit programs that can be analyzedI finite-state, loop-free, bounded arithmetic, . . .
I Partial/unsound verification approachesI Testing: analyze program executions on a fixed input set
if (x-100<=0)if (y-100<=0)if (x+y-200==0)
crash();
If x and y are 32-bit integers, whatis the probability of a crash?I 1/264
Testing is hard!
42 / 141
Deductive Verification – Living with Undecidability
I Programs that “sometimes” diverge
I Limit programs that can be analyzedI finite-state, loop-free, bounded arithmetic, . . .
I Partial/unsound verification approachesI Testing: analyze program executions on a fixed input set
if (x-100<=0)if (y-100<=0)if (x+y-200==0)
crash();
If x and y are 32-bit integers, whatis the probability of a crash?I 1/264
Testing is hard!
43 / 141
Deductive Verification – Living with Undecidability
I Programs that “sometimes” diverge
I Limit programs that can be analyzedI finite-state, loop-free, bounded arithmetic, . . .
I Partial/unsound verification approachesI Testing: analyze program executions on a fixed input set
I AbstractionsI Model checking: verify a superset of program executions
I User assistanceI Deductive verification: using program annotations (e.g. loop invariants)
Algorithmic approach to deductive verification: (my research area)
I automate the generation of annotations,I fully automatic, push-button verification for classes of programs
44 / 141
Deductive Verification – Living with Undecidability
I Programs that “sometimes” diverge
I Limit programs that can be analyzedI finite-state, loop-free, bounded arithmetic, . . .
I Partial/unsound verification approachesI Testing: analyze program executions on a fixed input set
I AbstractionsI Model checking: verify a superset of program executions
I User assistanceI Deductive verification: using program annotations (e.g. loop invariants)
Algorithmic approach to deductive verification: (my research area)
I automate the generation of annotations,I fully automatic, push-button verification for classes of programs
45 / 141
Deductive Verification – Living with Undecidability
I Programs that “sometimes” diverge
I Limit programs that can be analyzedI finite-state, loop-free, bounded arithmetic, . . .
I Partial/unsound verification approachesI Testing: analyze program executions on a fixed input set
I AbstractionsI Model checking: verify a superset of program executions
I User assistanceI Deductive verification: using program annotations (e.g. loop invariants)
Algorithmic approach to deductive verification: (my research area)
I automate the generation of annotations,I fully automatic, push-button verification for classes of programs
46 / 141
Deductive Verification of Programs
Program
Specification
Deductiveverifier
Theoremprover
VC:
SAT/SMT/ FOL
Formula
Correct(Valid)
Incorrect(Unsat)
VC
VC
I Verification condition (VC): φ s.t. the program is correct iff φ isvalid
I Available tools: Dafny (Microsoft), Why3, KeY, ESC/Java, . . .
47 / 141
Deductive Verification of Programs in Practice
Program
Specification
Deductiveverifier
Theoremprover
VC:
SAT/SMT/ FOL
Formula
Correct(Valid)
Incorrect(Unsat)
VC
VC
I Verification condition (VC): A logical formula φ s.t. the program iscorrect iff φ is valid
I Available tools: Dafny (Microsoft), Why3, KeY, ESC/Java, . . .
48 / 141
Deductive Verification of Programs in Practice
Program
Specification
Deductiveverifier
Theoremprover
VC:
SAT/SMT/ FOL
Formula
Correct(Valid)
Incorrect(Unsat)
I Verification condition (VC): SAT/SMT/FOL formula φ s.t. theprogram is correct iff φ is valid
I Available tools: Dafny (Microsoft), Why3, KeY, ESC/Java, . . .
49 / 141
Deductive Verification of Programs in Dafny
Revisiting our allocateArray example
50 / 141
Deductive Verification of Programs in Dafny
method allocateArray(a:array<int>, length:int)
requires 0<=length<a.Lengthmodifies aensures forall k::0<=k<length==>a[k]!=0
{var i:int;i:=0;while (i<length)
invariant (forall k::0<=k<i&& k<length==>a[k]!=0);
{a[i]:=1; i:=i+1;
}}
51 / 141
Deductive Verification of Programs in Dafny
method allocateArray(a:array<int>, length:int)requires 0<=length<a.Lengthmodifies a
ensures forall k::0<=k<length==>a[k]!=0
{var i:int;i:=0;while (i<length)
invariant (forall k::0<=k<i&& k<length==>a[k]!=0);
{a[i]:=1; i:=i+1;
}}
52 / 141
Deductive Verification of Programs in Dafny
method allocateArray(a:array<int>, length:int)requires 0<=length<a.Lengthmodifies aensures forall k::0<=k<length==>a[k]!=0{var i:int;i:=0;while (i<length)
invariant (forall k::0<=k<i&& k<length==>a[k]!=0);
{a[i]:=1; i:=i+1;
}}
53 / 141
Deductive Verification of Programs in Dafny
method allocateArray(a:array<int>, length:int)requires 0<=length<a.Lengthmodifies aensures forall k::0<=k<length==>a[k]!=0{var i:int;i:=0;while (i<length)invariant (forall k::0<=k<i&& k<length==>a[k]!=0);
{a[i]:=1; i:=i+1;
}}
54 / 141
Deductive Verification of Programs
I Living with undecidability;
I Algorithmic approach, using Hoare logic;
I Automated approach, thanks to SAT/SMT solving and theoremproving.
55 / 141
Deductive Verification of Programs
Tentative list of topics to be addressed:I Small imperative language IMP
I Syntax and semantics
I Hoare logic: basis of all deductive verification techniques
I Deductive verification of IMP
I Axiomatic Semantics
I Predicate transformers - for algorithmic verification
I Inferring loop invariants automatically
56 / 141
Outline
Introduction
Small Imperative Language IMP
57 / 141
Small Imperative Language IMP – Syntax
We consider a small imperative language IMP.
Syntactic Sets of IMP
• Int positive and negative (integer) numerals n,m, . . . (e.g. −5, 0, 10)
• Loc locations x , y , z, . . .• AExp arithmetic expressions a• BExp boolean expressions b• P programs p
58 / 141
Small Imperative Language IMP – Syntax
Abstract Syntax of IMP: Arithmetic Expressions AExp
a ::= n for n ∈ Int
| x for x ∈ Loc
| a1 + a2 for a1,a2 ∈ AExp
| a1 − a2 for a1,a2 ∈ AExp
| a1 ∗ a2 for a1,a2 ∈ AExp
| a1/a2 for a1,a2 ∈ AExp
I In the abstract synthax, we omit parantheses.
2 + 3 ∗ 4− 5
can be parsed as 2 + ((3 ∗ 4)− 5 or as (2 + 3) ∗ (4− 5), depending onthe concrete syntax (e.g. using operator precedence).
I 3 + 5 is not syntactically identical to 5 + 3.But, (3 + 5) is syntactically identical to 3 + 5.
59 / 141
Small Imperative Language IMP – Syntax
Abstract Syntax of IMP: Arithmetic Expressions AExp
a ::= n for n ∈ Int
| x for x ∈ Loc
| a1 + a2 for a1,a2 ∈ AExp
| a1 − a2 for a1,a2 ∈ AExp
| a1 ∗ a2 for a1,a2 ∈ AExp
| a1/a2 for a1,a2 ∈ AExp
I In the abstract synthax, we omit parantheses.
2 + 3 ∗ 4− 5
can be parsed as 2 + ((3 ∗ 4)− 5 or as (2 + 3) ∗ (4− 5), depending onthe concrete syntax (e.g. using operator precedence).
I 3 + 5 is not syntactically identical to 5 + 3.But, (3 + 5) is syntactically identical to 3 + 5.
60 / 141
Small Imperative Language IMP – Syntax
Abstract Syntax of IMP: Arithmetic Expressions AExp
a ::= n for n ∈ Int
| x for x ∈ Loc
| a1 + a2 for a1,a2 ∈ AExp
| a1 − a2 for a1,a2 ∈ AExp
| a1 ∗ a2 for a1,a2 ∈ AExp
| a1/a2 for a1,a2 ∈ AExp
I In the abstract synthax, we omit parantheses.
2 + 3 ∗ 4− 5
can be parsed as 2 + ((3 ∗ 4)− 5 or as (2 + 3) ∗ (4− 5), depending onthe concrete syntax (e.g. using operator precedence).
I 3 + 5 is not syntactically identical to 5 + 3.But, (3 + 5) is syntactically identical to 3 + 5.
61 / 141
Small Imperative Language IMP – Syntax
Abstract Syntax of IMP: Boolean Expressions BExp
b ::= true
| false
| a1 AOP a2 for a1,a2 ∈ AExp and AOP ∈ {=, <,>,≤,≥}| ¬b for b ∈ BExp
| b1 BOP b2 for b1,b2 ∈ BExp and BOP ∈ {∧,∨}
62 / 141
Small Imperative Language IMP – Syntax
Abstract Syntax of IMP: Programs P
p ::= skip
| abort
| x := a for x ∈ Loc and a ∈ AExp
| p1; p2 for p1,p2 ∈ P
| if b then p1 else p2 for b ∈ BExp and p1,p2 ∈ P
| while b do p od for b ∈ BExp and p ∈ P
63 / 141
Small Imperative Language IMP – Syntax
Example of an IMP Program
p
=⇒ p1; p2
=⇒ p1; p3; p4
=⇒∗ x := e1; y := e2; while b do p5 od
=⇒∗ x := 10; y := 0; while a1 > a2 do p6; p7 od
=⇒∗ x := 10; y := 0; while x > 0 do y := y + x ; x := x − 1 od
64 / 141
Small Imperative Language IMP – Syntax
Example of an IMP Program
p =⇒ p1; p2
=⇒ p1; p3; p4
=⇒∗ x := e1; y := e2; while b do p5 od
=⇒∗ x := 10; y := 0; while a1 > a2 do p6; p7 od
=⇒∗ x := 10; y := 0; while x > 0 do y := y + x ; x := x − 1 od
65 / 141
Small Imperative Language IMP – Syntax
Example of an IMP Program
p =⇒ p1; p2
=⇒ p1; p3; p4
=⇒∗ x := e1; y := e2; while b do p5 od
=⇒∗ x := 10; y := 0; while a1 > a2 do p6; p7 od
=⇒∗ x := 10; y := 0; while x > 0 do y := y + x ; x := x − 1 od
66 / 141
Small Imperative Language IMP – Syntax
Example of an IMP Program
p =⇒ p1; p2
=⇒ p1; p3; p4
=⇒∗ x := e1; y := e2; while b do p5 od
=⇒∗ x := 10; y := 0; while a1 > a2 do p6; p7 od
=⇒∗ x := 10; y := 0; while x > 0 do y := y + x ; x := x − 1 od
67 / 141
Small Imperative Language IMP – Semantics
I Meaning of IMP programs and expressions depends on thevalues of variables in locations.
I A state σ is a function from Loc to Int.
I σ(x) is the value/content of locations x in state σ
I the set of states Σ = {σ|σ : Loc→ Int}
68 / 141
Small Imperative Language IMP – Semantics
I Meaning of IMP programs and expressions depends on thevalues of variables in locations.
I A state σ is a function from Loc to Int.
I σ(x) is the value/content of locations x in state σ
I the set of states Σ = {σ|σ : Loc→ Int}
69 / 141
Small Imperative Language IMP – Semantics
I Meaning of IMP programs and expressions depends on thevalues of variables in locations.
I A state σ is a function from Loc to Int.
I σ(x) is the value/content of locations x in state σ
I the set of states Σ = {σ|σ : Loc→ Int}
70 / 141
Programs as State TransformersInput States Output States
Program
Program
Program
I Several inputs may be mapped to the same output.I Some inputs are not mapped to any output.
(Program aborts or loops.)I Some outputs are not reached from any input.I One input may be mapped to several outputs (non-determinism).
71 / 141
Programs as State TransformersInput States Output States
Program
Program
Program
I Several inputs may be mapped to the same output.
I Some inputs are not mapped to any output.(Program aborts or loops.)
I Some outputs are not reached from any input.I One input may be mapped to several outputs (non-determinism).
72 / 141
Programs as State TransformersInput States Output States
Program
Program
Program
I Several inputs may be mapped to the same output.I Some inputs are not mapped to any output.
(Program aborts or loops.)
I Some outputs are not reached from any input.I One input may be mapped to several outputs (non-determinism).
73 / 141
Programs as State TransformersInput States Output States
Program
Program
Program
I Several inputs may be mapped to the same output.I Some inputs are not mapped to any output.
(Program aborts or loops.)I Some outputs are not reached from any input.
I One input may be mapped to several outputs (non-determinism).
74 / 141
Programs as State TransformersInput States Output States
Program
Program
Program
I Several inputs may be mapped to the same output.I Some inputs are not mapped to any output.
(Program aborts or loops.)I Some outputs are not reached from any input.I One input may be mapped to several outputs (non-determinism).
75 / 141
Small Imperative Language IMP – Semantics
I Evaluation of IMP expressions:
I Ternary relation on an AExp/BExp expression, a state σ and avalue v
I Denoted as 〈exp, σ〉 → v , where exp ∈ AExp or exp ∈ BExp:
“Expression exp in state σ evaluates to value v ”.
Operational semantics: “mapping of expressions to values”
76 / 141
Small Imperative Language IMP – Operational Semantics
I Evaluation of IMP expressions:
I Ternary relation on an AExp/BExp expression, a state σ and avalue v
I Denoted as 〈exp, σ〉 → v , where exp ∈ AExp or exp ∈ BExp:
“Expression exp in state σ evaluates to value v ”.
Operational semantics: “mapping of expressions to values”
I Why no state on the right of→?
Evaluation of IMP expressions has no side-effects (the state remainsunchanged)
I Can evaluations of expressions be considered as a function of 2arguments exp and σ?
Only if there is a unique value v for 〈exp, σ〉 → v
77 / 141
Small Imperative Language IMP – Operational Semantics
I Evaluation of IMP expressions:
I Ternary relation on an AExp/BExp expression, a state σ and avalue v
I Denoted as 〈exp, σ〉 → v , where exp ∈ AExp or exp ∈ BExp:
“Expression exp in state σ evaluates to value v ”.
Operational semantics: “mapping of expressions to values”
I Why no state on the right of→?
Evaluation of IMP expressions has no side-effects (the state remainsunchanged)
I Can evaluations of expressions be considered as a function of 2arguments exp and σ?
Only if there is a unique value v for 〈exp, σ〉 → v
78 / 141
Small Imperative Language IMP – Operational Semantics
I Evaluation of IMP expressions:
I Ternary relation on an AExp/BExp expression, a state σ and avalue v
I Denoted as 〈exp, σ〉 → v , where exp ∈ AExp or exp ∈ BExp:
“Expression exp in state σ evaluates to value v ”.
Operational semantics: “mapping of expressions to values”
I Why no state on the right of→?
Evaluation of IMP expressions has no side-effects (the state remainsunchanged)
I Can evaluations of expressions be considered as a function of 2arguments exp and σ?
Only if there is a unique value v for 〈exp, σ〉 → v
79 / 141
Small Imperative Language IMP – Operational Semantics
I Evaluation of IMP expressions:
I Ternary relation on an AExp/BExp expression, a state σ and avalue v
I Denoted as 〈exp, σ〉 → v , where exp ∈ AExp or exp ∈ BExp:
“Expression exp in state σ evaluates to value v ”.
Operational semantics: “mapping of expressions to values”
I Why no state on the right of→?
Evaluation of IMP expressions has no side-effects (the state remainsunchanged)
I Can evaluations of expressions be considered as a function of 2arguments exp and σ?
Only if there is a unique value v for 〈exp, σ〉 → v
80 / 141
Small Imperative Language IMP – Operational Semantics
I Evaluation of IMP expressions:
I Ternary relation on an AExp/BExp expression, a state σ and avalue v
I Denoted as 〈exp, σ〉 → v , where exp ∈ AExp or exp ∈ BExp:
“Expression exp in state σ evaluates to value v ”.
Operational semantics: “mapping of expressions to values”
I The pair 〈exp, σ〉 is:I an arithmetic expression configuration, for exp ∈ AExp;I a boolean expression configuration, for exp ∈ BExp;
81 / 141
Small Imperative Language IMP – Operational Semantics
I Evaluation of IMP programs:
I Ternary relation on a program p, a state σ and a new state σ′
I Denoted as 〈p, σ〉 → σ′:
“Executing program p from state σ terminates in final state σ′”.
82 / 141
Small Imperative Language IMP – Operational Semantics
I Evaluation of IMP programs:
I Ternary relation on a program p, a state σ and a new state σ′
I Denoted as 〈p, σ〉 → σ′:
“Executing program p from state σ terminates in final state σ′”.
I Execution of a program has effectI but no direct value
I “result” of a program is a new state σ′
I Evaluation of a program:I may terminate in a final state
I may diverge and never yield a final state
83 / 141
Small Imperative Language IMP – Operational Semantics
I Evaluation of IMP programs:
I Ternary relation on a program p, a state σ and a new state σ′
I Denoted as 〈p, σ〉 → σ′:
“Executing program p from state σ terminates in final state σ′”.
I Execution of a program has effectI but no direct value
I “result” of a program is a new state σ′
I Evaluation of a program:I may terminate in a final state
I may diverge and never yield a final state
84 / 141
Small Imperative Language IMP – Operational Semantics
I Evaluation of IMP programs:
I Ternary relation on a program p, a state σ and a new state σ′
I Denoted as 〈p, σ〉 → σ′:
“Executing program p from state σ terminates in final state σ′”.
I Can evaluations of programs be considered as a function of 2arguments p and σ?
Only if there is a unique successor state
85 / 141
Small Imperative Language IMP – Operational Semantics
I Evaluation of IMP programs:
I Ternary relation on a program p, a state σ and a new state σ′
I Denoted as 〈p, σ〉 → σ′:
“Executing program p from state σ terminates in final state σ′”.
I Can evaluations of programs be considered as a function of 2arguments p and σ?
Only if there is a unique successor state
86 / 141
Small Imperative Language IMP – Operational Semantics
I Evaluation of IMP programs:
I Ternary relation on a program p, a state σ and a new state σ′
I Denoted as 〈p, σ〉 → σ′:
“Executing program p from state σ terminates in final state σ′”.
I The pair 〈p, σ〉 is a program configuration from which it remainsto execute p from state σ.
I A final state is also a program configuration, called finalconfiguration.
I Set of program configurations C = (P × Σ) ∪ Σ
I Transition relation ==> of IMP programs is a relation over C × CI 〈p, σ〉 ==> 〈p′, σ′〉 intermediate step of program executionI 〈p, σ〉 ==> σ′ last step of program execution
87 / 141
Small Imperative Language IMP – Operational Semantics
I Evaluation of IMP programs:
I Ternary relation on a program p, a state σ and a new state σ′
I Denoted as 〈p, σ〉 → σ′:
“Executing program p from state σ terminates in final state σ′”.
I The pair 〈p, σ〉 is a program configuration from which it remainsto execute p from state σ.
I A final state is also a program configuration, called finalconfiguration.
I Set of program configurations C = (P × Σ) ∪ Σ
I Transition relation ==> of IMP programs is a relation over C × CI 〈p, σ〉 ==> 〈p′, σ′〉 intermediate step of program executionI 〈p, σ〉 ==> σ′ last step of program execution
88 / 141
Small Imperative Language IMP – Operational Semantics
I Evaluation of IMP programs:
I Ternary relation on a program p, a state σ and a new state σ′
I Denoted as 〈p, σ〉 → σ′:
“Executing program p from state σ terminates in final state σ′”.
I The pair 〈p, σ〉 is a program configuration from which it remainsto execute p from state σ.
I A final state is also a program configuration, called finalconfiguration.
I Set of program configurations C = (P × Σ) ∪ ΣI Transition relation ==> of IMP programs is a relation over C × C
I 〈p, σ〉 ==> 〈p′, σ′〉 intermediate step of program executionI 〈p, σ〉 ==> σ′ last step of program execution
89 / 141
Small Imperative Language IMP – Operational Semantics
Evaluation Rule Notation:
F1 . . . Fk
G,
to denote “if F1, . . . ,Fk , then G”.
When k = 0, then G is an axiom:
G.
90 / 141
Small Imperative Language IMP – Operational Semantics
Note: In 〈a, σ〉 → v , the value v is an integer value.
Evaluation Rules for AExp
〈n, σ〉 → n, where n ∈ Z represents the integer number corresponding to n ∈ Int
〈x , σ〉 → σ(x)
〈a1, σ〉 → n1 〈a2, σ〉 → n2
〈a1 + a2, σ〉 → n1 +Z n2, where +Z is the integer sum operator
〈a1, σ〉 → n1 〈a2, σ〉 → n2
〈a1 − a2, σ〉 → n1 −Z n2, where−Z is the integer substraction operator
〈a1, σ〉 → n1 〈a2, σ〉 → n2
〈a1 ∗ a2, σ〉 → n1 ∗Z n2, where ∗Z is the integer product operator
〈a1, σ〉 → n1 〈a2, σ〉 → n2
〈a1/a2, σ〉 → n1/Z n2, where /Z is the of integer division operator
91 / 141
Small Imperative Language IMP – Operational Semantics
Note: In 〈a, σ〉 → v , the value v is an integer value.
Evaluation Rules for AExp
〈n, σ〉 → n, where n ∈ Z represents the integer number corresponding to n ∈ Int
〈x , σ〉 → σ(x)
〈a1, σ〉 → n1 〈a2, σ〉 → n2
〈a1 + a2, σ〉 → n1 +Z n2, where +Z is the integer sum operator
〈a1, σ〉 → n1 〈a2, σ〉 → n2
〈a1 − a2, σ〉 → n1 −Z n2, where−Z is the integer substraction operator
〈a1, σ〉 → n1 〈a2, σ〉 → n2
〈a1 ∗ a2, σ〉 → n1 ∗Z n2, where ∗Z is the integer product operator
〈a1, σ〉 → n1 〈a2, σ〉 → n2
〈a1/a2, σ〉 → n1/Z n2, where /Z is the of integer division operator
92 / 141
Small Imperative Language IMP – Operational Semantics
Note: In 〈a, σ〉 → v , the value v is an integer value.
Evaluation Rules for AExp
〈n, σ〉 → n, where n ∈ Z represents the integer number corresponding to n ∈ Int
〈x , σ〉 → σ(x)
〈a1, σ〉 → n1 〈a2, σ〉 → n2
〈a1 + a2, σ〉 → n1 +Z n2, where +Z is the integer sum operator
〈a1, σ〉 → n1 〈a2, σ〉 → n2
〈a1 − a2, σ〉 → n1 −Z n2, where−Z is the integer substraction operator
〈a1, σ〉 → n1 〈a2, σ〉 → n2
〈a1 ∗ a2, σ〉 → n1 ∗Z n2, where ∗Z is the integer product operator
〈a1, σ〉 → n1 〈a2, σ〉 → n2
〈a1/a2, σ〉 → n1/Z n2, where /Z is the of integer division operator
93 / 141
Small Imperative Language IMP – Operational Semantics
Note: In 〈a, σ〉 → v , the value v is an integer value.
Evaluation Rules for AExp
〈n, σ〉 → n, where n ∈ Z represents the integer number corresponding to n ∈ Int
〈x , σ〉 → σ(x)
〈a1, σ〉 → n1 〈a2, σ〉 → n2
〈a1 + a2, σ〉 → n1 +Z n2, where +Z is the integer sum operator
〈a1, σ〉 → n1 〈a2, σ〉 → n2
〈a1 − a2, σ〉 → n1 −Z n2, where−Z is the integer substraction operator
〈a1, σ〉 → n1 〈a2, σ〉 → n2
〈a1 ∗ a2, σ〉 → n1 ∗Z n2, where ∗Z is the integer product operator
〈a1, σ〉 → n1 〈a2, σ〉 → n2
〈a1/a2, σ〉 → n1/Z n2, where /Z is the of integer division operator
94 / 141
Small Imperative Language IMP – Operational Semantics
Note: In 〈a, σ〉 → v , the value v is an integer value.
Evaluation Rules for AExp
〈n, σ〉 → n, where n ∈ Z represents the integer number corresponding to n ∈ Int
〈x , σ〉 → σ(x)
〈a1, σ〉 → n1 〈a2, σ〉 → n2
〈a1 + a2, σ〉 → n1 +Z n2, where +Z is the integer sum operator
〈a1, σ〉 → n1 〈a2, σ〉 → n2
〈a1 − a2, σ〉 → n1 −Z n2, where−Z is the integer substraction operator
〈a1, σ〉 → n1 〈a2, σ〉 → n2
〈a1 ∗ a2, σ〉 → n1 ∗Z n2, where ∗Z is the integer product operator
〈a1, σ〉 → n1 〈a2, σ〉 → n2
〈a1/a2, σ〉 → n1/Z n2, where /Z is the of integer division operator
95 / 141
Small Imperative Language IMP – Operational Semantics
An Example of Evaluating a ∈ AExp
Let a be (x + 5) + (8 + 10).Consider the state σ0 with σ0(x) = 0.
〈x , σ0〉 →
0locations
〈5, σ0〉 →
5numbers
〈x + 5, σ0〉 →
5sum
〈8, σ0〉 → 8
numbers
〈10, σ0〉 → 10
numbers
〈8 + 10, σ0〉 →
18sum
〈(x + 5) + (8 + 10), σ0〉 →
23sum
The above structure of evaluation rules illustrates the derivation tree, orsimply derivation of 〈a, σ0〉 → 23.
96 / 141
Small Imperative Language IMP – Operational Semantics
An Example of Evaluating a ∈ AExp
Let a be (x + 5) + (8 + 10).Consider the state σ0 with σ0(x) = 0.
〈x , σ0〉 →
0locations
〈5, σ0〉 →
5numbers
〈x + 5, σ0〉 →
5sum
〈8, σ0〉 → 8
numbers
〈10, σ0〉 → 10
numbers
〈8 + 10, σ0〉 →
18sum
〈(x + 5) + (8 + 10), σ0〉 →
23
sum
The above structure of evaluation rules illustrates the derivation tree, orsimply derivation of 〈a, σ0〉 → 23.
97 / 141
Small Imperative Language IMP – Operational Semantics
An Example of Evaluating a ∈ AExp
Let a be (x + 5) + (8 + 10).Consider the state σ0 with σ0(x) = 0.
〈x , σ0〉 →
0locations
〈5, σ0〉 →
5numbers
〈x + 5, σ0〉 →
5
sum
〈8, σ0〉 → 8
numbers
〈10, σ0〉 → 10
numbers
〈8 + 10, σ0〉 →
18sum
〈(x + 5) + (8 + 10), σ0〉 →
23
sum
The above structure of evaluation rules illustrates the derivation tree, orsimply derivation of 〈a, σ0〉 → 23.
98 / 141
Small Imperative Language IMP – Operational Semantics
An Example of Evaluating a ∈ AExp
Let a be (x + 5) + (8 + 10).Consider the state σ0 with σ0(x) = 0.
〈x , σ0〉 → 0locations
〈5, σ0〉 → 5numbers
〈x + 5, σ0〉 → 5sum
〈8, σ0〉 → 8
numbers
〈10, σ0〉 → 10
numbers
〈8 + 10, σ0〉 →
18sum
〈(x + 5) + (8 + 10), σ0〉 →
23
sum
The above structure of evaluation rules illustrates the derivation tree, orsimply derivation of 〈a, σ0〉 → 23.
99 / 141
Small Imperative Language IMP – Operational Semantics
An Example of Evaluating a ∈ AExp
Let a be (x + 5) + (8 + 10).Consider the state σ0 with σ0(x) = 0.
〈x , σ0〉 → 0locations
〈5, σ0〉 → 5numbers
〈x + 5, σ0〉 → 5sum
〈8, σ0〉 → 8numbers
〈10, σ0〉 → 10numbers
〈8 + 10, σ0〉 → 18sum
〈(x + 5) + (8 + 10), σ0〉 →
23
sum
The above structure of evaluation rules illustrates the derivation tree, orsimply derivation of 〈a, σ0〉 → 23.
100 / 141
Small Imperative Language IMP – Operational Semantics
An Example of Evaluating a ∈ AExp
Let a be (x + 5) + (8 + 10).Consider the state σ0 with σ0(x) = 0.
〈x , σ0〉 → 0locations
〈5, σ0〉 → 5numbers
〈x + 5, σ0〉 → 5sum
〈8, σ0〉 → 8numbers
〈10, σ0〉 → 10numbers
〈8 + 10, σ0〉 → 18sum
〈(x + 5) + (8 + 10), σ0〉 → 23sum
The above structure of evaluation rules illustrates the derivation tree, orsimply derivation of 〈a, σ0〉 → 23.
101 / 141
Small Imperative Language IMP – Operational Semantics
An Example of Evaluating a ∈ AExp
Let a be (x + 5) + (8 + 10).Consider the state σ0 with σ0(x) = 0.
〈x , σ0〉 → 0locations
〈5, σ0〉 → 5numbers
〈x + 5, σ0〉 → 5sum
〈8, σ0〉 → 8numbers
〈10, σ0〉 → 10numbers
〈8 + 10, σ0〉 → 18sum
〈(x + 5) + (8 + 10), σ0〉 → 23sum
The above structure of evaluation rules illustrates the derivation tree, orsimply derivation of 〈a, σ0〉 → 23.
102 / 141
Small Imperative Language IMP – Operational Semantics
Note: In 〈b, σ〉 → v , the value v is a boolean value/truth value.
103 / 141
Small Imperative Language IMP – Operational Semantics
Evaluation Rules for BExp
〈true, σ〉 → true, where true represents the boolean value 1 (true)
〈false, σ〉 → false, where false represents the boolean value 0 (false)
〈a1, σ〉 → n1 〈a2, σ〉 → n2
〈a1 = a2, σ〉 → true, if n1 and n2 are equal
〈a1, σ〉 → n1 〈a2, σ〉 → n2
〈a1 = a2, σ〉 → false, if n1 and n2 are not equal
〈a1, σ〉 → n1 〈a2, σ〉 → n2
〈a1 ≤ a2, σ〉 → true, if n1 is less than or equal to n2
〈a1, σ〉 → n1 〈a2, σ〉 → n2
〈a1 ≤ a2, σ〉 → false, if n1 is not less than or equal to n2
104 / 141
Small Imperative Language IMP – Operational Semantics
Evaluation Rules for BExp
〈true, σ〉 → true, where true represents the boolean value 1 (true)
〈false, σ〉 → false, where false represents the boolean value 0 (false)
〈a1, σ〉 → n1 〈a2, σ〉 → n2
〈a1 = a2, σ〉 → true, if n1 and n2 are equal
〈a1, σ〉 → n1 〈a2, σ〉 → n2
〈a1 = a2, σ〉 → false, if n1 and n2 are not equal
〈a1, σ〉 → n1 〈a2, σ〉 → n2
〈a1 ≤ a2, σ〉 → true, if n1 is less than or equal to n2
〈a1, σ〉 → n1 〈a2, σ〉 → n2
〈a1 ≤ a2, σ〉 → false, if n1 is not less than or equal to n2
105 / 141
Small Imperative Language IMP – Operational Semantics
Evaluation Rules for BExp
〈true, σ〉 → true, where true represents the boolean value 1 (true)
〈false, σ〉 → false, where false represents the boolean value 0 (false)
〈a1, σ〉 → n1 〈a2, σ〉 → n2
〈a1 = a2, σ〉 → true, if n1 and n2 are equal
〈a1, σ〉 → n1 〈a2, σ〉 → n2
〈a1 = a2, σ〉 → false, if n1 and n2 are not equal
〈a1, σ〉 → n1 〈a2, σ〉 → n2
〈a1 ≤ a2, σ〉 → true, if n1 is less than or equal to n2
〈a1, σ〉 → n1 〈a2, σ〉 → n2
〈a1 ≤ a2, σ〉 → false, if n1 is not less than or equal to n2
106 / 141
Small Imperative Language IMP – Operational Semantics
Evaluation Rules for BExp (contd)
〈a1, σ〉 → n1 〈a2, σ〉 → n2
〈a1 ≥ a2, σ〉 → true, if n1 is greater than or equal to n2
〈a1, σ〉 → n1 〈a2, σ〉 → n2
〈a1 ≥ a2, σ〉 → false, if n1 is not greater than or equal to n2
〈a1, σ〉 → n1 〈a2, σ〉 → n2
〈a1 < a2, σ〉 → true, if n1 is less than n2
〈a1, σ〉 → n1 〈a2, σ〉 → n2
〈a1 < a2, σ〉 → false, if n1 is not less than n2
〈a1, σ〉 → n1 〈a2, σ〉 → n2
〈a1 > a2, σ〉 → true, if n1 is greater than n2
〈a1, σ〉 → n1 〈a2, σ〉 → n2
〈a1 > a2, σ〉 → false, if n1 is not greater than n2
107 / 141
Small Imperative Language IMP – Operational Semantics
Evaluation Rules for BExp (contd)
〈b, σ〉 → true〈¬b, σ〉 → false
neg〈b, σ〉 → false〈¬b, σ〉 → true
neg
〈b1, σ〉 → t1 〈b2, σ〉 → t2〈b1 ∧ b2, σ〉 → t
, where t is true if both t1 and t2are true, and is false otherwise.
〈b1, σ〉 → t1 〈b2, σ〉 → t2〈b1 ∨ b2, σ〉 → t
, where t is false if both t1 and t2are false, and is true otherwise.
108 / 141
Small Imperative Language IMP – Operational Semantics
Evaluation Rules for BExp (contd)
〈b, σ〉 → true〈¬b, σ〉 → false
neg〈b, σ〉 → false〈¬b, σ〉 → true
neg
〈b1, σ〉 → t1 〈b2, σ〉 → t2〈b1 ∧ b2, σ〉 → t
, where t is true if both t1 and t2are true, and is false otherwise.
〈b1, σ〉 → t1 〈b2, σ〉 → t2〈b1 ∨ b2, σ〉 → t
, where t is false if both t1 and t2are false, and is true otherwise.
109 / 141
Small Imperative Language IMP – Operational Semantics
Evaluation Rules for BExp (contd)
〈b, σ〉 → true〈¬b, σ〉 → false
neg〈b, σ〉 → false〈¬b, σ〉 → true
neg
〈b1, σ〉 → t1 〈b2, σ〉 → t2〈b1 ∧ b2, σ〉 → t
, where t is true if both t1 and t2are true, and is false otherwise.
〈b1, σ〉 → t1 〈b2, σ〉 → t2〈b1 ∨ b2, σ〉 → t
, where t is false if both t1 and t2are false, and is true otherwise.
110 / 141
Small Imperative Language IMP – Operational Semantics
Evaluation Rules for P
〈skip, σ〉 →
σ
〈abort, σ〉 →
undefined
〈a, σ〉 → v
〈x := a, σ〉 →
σ[x/v ]
Notation: We write σ[x/v ] to denote the state obtained from σ by replacing xby v . That is:
σ[x/v ](y) =
{v , if y = x ,σ(y), otherwise
111 / 141
Small Imperative Language IMP – Operational Semantics
Evaluation Rules for P
〈skip, σ〉 → σ 〈abort, σ〉 6→ undefined
Evaluation of IMP programs is a partial relation!
〈a, σ〉 → v
〈x := a, σ〉 →
σ[x/v ]
Notation: We write σ[x/v ] to denote the state obtained from σ by replacing xby v . That is:
σ[x/v ](y) =
{v , if y = x ,σ(y), otherwise
112 / 141
Small Imperative Language IMP – Operational Semantics
Evaluation Rules for P
〈skip, σ〉 → σ 〈abort, σ〉 6→ undefined
〈a, σ〉 → v
〈x := a, σ〉 →
σ[x/v ]
Notation: We write σ[x/v ] to denote the state obtained from σ by replacing xby v . That is:
σ[x/v ](y) =
{v , if y = x ,σ(y), otherwise
113 / 141
Small Imperative Language IMP – Operational Semantics
Evaluation Rules for P
〈skip, σ〉 → σ 〈abort, σ〉 6→ undefined
〈a, σ〉 → v〈x := a, σ〉 → σ[x/v ]
Notation: We write σ[x/v ] to denote the state obtained from σ by replacing xby v . That is:
σ[x/v ](y) =
{v , if y = x ,σ(y), otherwise
114 / 141
Small Imperative Language IMP – Operational Semantics
Evaluation Rules for P
〈skip, σ〉 → σ 〈abort, σ〉 6→ undefined
〈a, σ〉 → v〈x := a, σ〉 → σ[x/v ]
〈p1, σ〉 → σ′ 〈p2, σ′〉 → σ′′
〈p1; p2, σ〉 →
σ′′
〈b, σ〉 → true 〈p1, σ〉 → σ′
〈if b then p1 else p2, σ〉 →
σ′〈b, σ〉 → false 〈p2, σ〉 → σ′
〈if b then p1 else p2, σ〉 → σ′
〈b, σ〉 → false
〈while b do p od , σ〉 →
σ
〈b, σ〉 → true 〈p, σ〉 → σ′ 〈while b do p od , σ′〉 → σ′′
〈while b do p od , σ〉 →
σ′′
115 / 141
Small Imperative Language IMP – Operational Semantics
Evaluation Rules for P
〈skip, σ〉 → σ 〈abort, σ〉 6→ undefined
〈a, σ〉 → v〈x := a, σ〉 → σ[x/v ]
〈p1, σ〉 → σ′ 〈p2, σ′〉 → σ′′
〈p1; p2, σ〉 → σ′′
〈b, σ〉 → true 〈p1, σ〉 → σ′
〈if b then p1 else p2, σ〉 →
σ′〈b, σ〉 → false 〈p2, σ〉 → σ′
〈if b then p1 else p2, σ〉 → σ′
〈b, σ〉 → false
〈while b do p od , σ〉 →
σ
〈b, σ〉 → true 〈p, σ〉 → σ′ 〈while b do p od , σ′〉 → σ′′
〈while b do p od , σ〉 →
σ′′
116 / 141
Small Imperative Language IMP – Operational Semantics
Evaluation Rules for P
〈skip, σ〉 → σ 〈abort, σ〉 6→ undefined
〈a, σ〉 → v〈x := a, σ〉 → σ[x/v ]
〈p1, σ〉 → σ′ 〈p2, σ′〉 → σ′′
〈p1; p2, σ〉 →
σ′′
〈b, σ〉 → true 〈p1, σ〉 → σ′
〈if b then p1 else p2, σ〉 →
σ′〈b, σ〉 → false 〈p2, σ〉 → σ′
〈if b then p1 else p2, σ〉 → σ′
〈b, σ〉 → false
〈while b do p od , σ〉 →
σ
〈b, σ〉 → true 〈p, σ〉 → σ′ 〈while b do p od , σ′〉 → σ′′
〈while b do p od , σ〉 →
σ′′
117 / 141
Small Imperative Language IMP – Operational Semantics
Evaluation Rules for P
〈skip, σ〉 → σ 〈abort, σ〉 6→ undefined
〈a, σ〉 → v〈x := a, σ〉 → σ[x/v ]
〈p1, σ〉 → σ′ 〈p2, σ′〉 → σ′′
〈p1; p2, σ〉 →
σ′′
〈b, σ〉 → true 〈p1, σ〉 → σ′
〈if b then p1 else p2, σ〉 → σ′
〈b, σ〉 → false 〈p2, σ〉 → σ′
〈if b then p1 else p2, σ〉 → σ′
〈b, σ〉 → false
〈while b do p od , σ〉 →
σ
〈b, σ〉 → true 〈p, σ〉 → σ′ 〈while b do p od , σ′〉 → σ′′
〈while b do p od , σ〉 →
σ′′
118 / 141
Small Imperative Language IMP – Operational Semantics
Evaluation Rules for P
〈skip, σ〉 → σ 〈abort, σ〉 6→ undefined
〈a, σ〉 → v〈x := a, σ〉 → σ[x/v ]
〈p1, σ〉 → σ′ 〈p2, σ′〉 → σ′′
〈p1; p2, σ〉 →
σ′′
〈b, σ〉 → true 〈p1, σ〉 → σ′
〈if b then p1 else p2, σ〉 → σ′〈b, σ〉 → false 〈p2, σ〉 → σ′
〈if b then p1 else p2, σ〉 → σ′
〈b, σ〉 → false
〈while b do p od , σ〉 →
σ
〈b, σ〉 → true 〈p, σ〉 → σ′ 〈while b do p od , σ′〉 → σ′′
〈while b do p od , σ〉 →
σ′′
119 / 141
Small Imperative Language IMP – Operational Semantics
Evaluation Rules for P
〈skip, σ〉 → σ 〈abort, σ〉 6→ undefined
〈a, σ〉 → v〈x := a, σ〉 → σ[x/v ]
〈p1, σ〉 → σ′ 〈p2, σ′〉 → σ′′
〈p1; p2, σ〉 →
σ′′
〈b, σ〉 → true 〈p1, σ〉 → σ′
〈if b then p1 else p2, σ〉 → σ′〈b, σ〉 → false 〈p2, σ〉 → σ′
〈if b then p1 else p2, σ〉 → σ′
〈b, σ〉 → false
〈while b do p od , σ〉 →
σ
〈b, σ〉 → true 〈p, σ〉 → σ′ 〈while b do p od , σ′〉 → σ′′
〈while b do p od , σ〉 →
σ′′
120 / 141
Small Imperative Language IMP – Operational Semantics
Evaluation Rules for P
〈skip, σ〉 → σ 〈abort, σ〉 6→ undefined
〈a, σ〉 → v〈x := a, σ〉 → σ[x/v ]
〈p1, σ〉 → σ′ 〈p2, σ′〉 → σ′′
〈p1; p2, σ〉 →
σ′′
〈b, σ〉 → true 〈p1, σ〉 → σ′
〈if b then p1 else p2, σ〉 → σ′〈b, σ〉 → false 〈p2, σ〉 → σ′
〈if b then p1 else p2, σ〉 → σ′
〈b, σ〉 → false
〈while b do p od , σ〉 → σ
〈b, σ〉 → true 〈p, σ〉 → σ′ 〈while b do p od , σ′〉 → σ′′
〈while b do p od , σ〉 →
σ′′
121 / 141
Small Imperative Language IMP – Operational Semantics
Evaluation Rules for P
〈skip, σ〉 → σ 〈abort, σ〉 6→ undefined
〈a, σ〉 → v〈x := a, σ〉 → σ[x/v ]
〈p1, σ〉 → σ′ 〈p2, σ′〉 → σ′′
〈p1; p2, σ〉 →
σ′′
〈b, σ〉 → true 〈p1, σ〉 → σ′
〈if b then p1 else p2, σ〉 → σ′〈b, σ〉 → false 〈p2, σ〉 → σ′
〈if b then p1 else p2, σ〉 → σ′
〈b, σ〉 → false〈while b do p od , σ〉 → σ
〈b, σ〉 → true 〈p, σ〉 → σ′ 〈while b do p od , σ′〉 → σ′′
〈while b do p od , σ〉 →
σ′′
122 / 141
Small Imperative Language IMP – Operational Semantics
Evaluation Rules for P
〈skip, σ〉 → σ 〈abort, σ〉 6→ undefined
〈a, σ〉 → v〈x := a, σ〉 → σ[x/v ]
〈p1, σ〉 → σ′ 〈p2, σ′〉 → σ′′
〈p1; p2, σ〉 →
σ′′
〈b, σ〉 → true 〈p1, σ〉 → σ′
〈if b then p1 else p2, σ〉 → σ′〈b, σ〉 → false 〈p2, σ〉 → σ′
〈if b then p1 else p2, σ〉 → σ′
〈b, σ〉 → false〈while b do p od , σ〉 → σ
〈b, σ〉 → true 〈p, σ〉 → σ′ 〈while b do p od , σ′〉 → σ′′
〈while b do p od , σ〉 → σ′′
123 / 141
Small Imperative Language IMP – Operational Semantics
Evaluation Rules for P
〈skip, σ〉 → σ 〈abort, σ〉 6→ undefined
〈a, σ〉 → v〈x := a, σ〉 → σ[x/v ]
〈p1, σ〉 → σ′ 〈p2, σ′〉 → σ′′
〈p1; p2, σ〉 →
σ′′
〈b, σ〉 → true 〈p1, σ〉 → σ′
〈if b then p1 else p2, σ〉 → σ′〈b, σ〉 → false 〈p2, σ〉 → σ′
〈if b then p1 else p2, σ〉 → σ′
〈b, σ〉 → false〈while b do p od , σ〉 → σ
〈b, σ〉 → true 〈p, σ〉 → σ′ 〈while b do p od , σ′〉 → σ′′
〈while b do p od , σ〉 → σ′′
124 / 141
Small Imperative Language IMP – Operational Semantics
Summary:
The operational semantics of IMP is given by:
I Evaluation rules for AExp expressions,
I Evaluation rules for BExp expressions,
I Evaluation rules for P programs expressions,
by using (partial) evaluation relations.
125 / 141
Learning Objectives
I Understanding the task of deductive program verification
I Limitations and trends in deductive program verification
I Familiarize with the Dafny program verifier
I Syntax of the small imperative language IMP
I Operational semantics of IMP
126 / 141