Programming Languages and Compilers (CS 421)

Slides:



Advertisements
Similar presentations
Automated Theorem Proving Lecture 1. Program verification is undecidable! Given program P and specification S, does P satisfy S?
Advertisements

Semantics Static semantics Dynamic semantics attribute grammars
ICE1341 Programming Languages Spring 2005 Lecture #6 Lecture #6 In-Young Ko iko.AT. icu.ac.kr iko.AT. icu.ac.kr Information and Communications University.
Reasoning About Code; Hoare Logic, continued
Hoare’s Correctness Triplets Dijkstra’s Predicate Transformers
Rigorous Software Development CSCI-GA Instructor: Thomas Wies Spring 2012 Lecture 11.
Axiomatic Verification I Prepared by Stephen M. Thebaut, Ph.D. University of Florida Software Testing and Verification Lecture 17.
Copyright © 2006 Addison-Wesley. All rights reserved.1-1 ICS 410: Programming Languages Chapter 3 : Describing Syntax and Semantics Axiomatic Semantics.
ISBN Chapter 3 Describing Syntax and Semantics.
Dynamic semantics Precisely specify the meanings of programs. Why? –programmers need to understand the meanings of programs they read –programmers need.
Copyright © 2006 Addison-Wesley. All rights reserved. 3.5 Dynamic Semantics Meanings of expressions, statements, and program units Static semantics – type.
Predicate Transformers
Fall Semantics Juan Carlos Guzmán CS 3123 Programming Languages Concepts Southern Polytechnic State University.
1 Semantic Description of Programming languages. 2 Static versus Dynamic Semantics n Static Semantics represents legal forms of programs that cannot be.
Announcements We are done with homeworks Second coding exam this week, in recitation –Times will be posted later today –If in doubt, show up for your regular.
CS 355 – Programming Languages
Axiomatic Semantics Dr. M Al-Mulhem ICS
Copyright © 2006 The McGraw-Hill Companies, Inc. Programming Languages 2nd edition Tucker and Noonan Chapter 18 Program Correctness To treat programming.
Dr. Muhammed Al-Mulhem 1ICS ICS 535 Design and Implementation of Programming Languages Part 1 Fundamentals (Chapter 4) Axiomatic Semantics ICS 535.
Software Verification Bertrand Meyer Chair of Software Engineering Lecture 2: Axiomatic semantics.
Describing Syntax and Semantics
Proving Program Correctness The Axiomatic Approach.
Proving Program Correctness The Axiomatic Approach.
9/18/20151 Programming Languages and Compilers (CS 421) Elsa L Gunter 2112 SC, UIUC Based in part on slides by Mattox.
CSI 3125, Axiomatic Semantics, page 1 Axiomatic semantics The assignment statement Statement composition The "if-then-else" statement The "while" statement.
1 Formal Semantics of Programming Languages “Program testing can be used to show the presence of bugs, but never to show their absence!” --Dijkstra.
Chapter 25 Formal Methods Formal methods Specify program using math Develop program using math Prove program matches specification using.
ISBN Chapter 3 Describing Semantics -Attribute Grammars -Dynamic Semantics.
CS 363 Comparative Programming Languages Semantics.
Reasoning about programs March CSE 403, Winter 2011, Brun.
Program Analysis and Verification Spring 2014 Program Analysis and Verification Lecture 4: Axiomatic Semantics I Roman Manevich Ben-Gurion University.
Chapter 3 Part II Describing Syntax and Semantics.
Semantics In Text: Chapter 3.
Languages and Compilers
COP4020 Programming Languages Introduction to Axiomatic Semantics Prof. Robert van Engelen.
13 Aug 2013 Program Verification. Proofs about Programs Why make you study logic? Why make you do proofs? Because we want to prove properties of programs.
Principle of Programming Lanugages 3: Compilation of statements Statements in C Assertion Hoare logic Department of Information Science and Engineering.
2/1/20161 Programming Languages and Compilers (CS 421) Grigore Rosu 2110 SC, UIUC Slides by Elsa Gunter, based in.
Cs7100(Prasad)L18-9WP1 Axiomatic Semantics Predicate Transformers.
Programming Language Concepts (CIS 635) Elsa L Gunter 4303 GITC NJIT,
1 Section 8.2 Program Correctness (for imperative programs) A theory of program correctness needs wffs, axioms, and inference rules. Wffs (called Hoare.
CSC3315 (Spring 2009)1 CSC 3315 Languages & Compilers Hamid Harroud School of Science and Engineering, Akhawayn University
C HAPTER 3 Describing Syntax and Semantics. D YNAMIC S EMANTICS Describing syntax is relatively simple There is no single widely acceptable notation or.
Programming Languages and Compilers (CS 421)
Programming Languages and Compilers (CS 421)
Reasoning About Code.
Reasoning about code CSE 331 University of Washington.
Formal Methods in Software Engineering 1
Programming Languages and Compilers (CS 421)
Lecture 5 Floyd-Hoare Style Verification
Programming Languages and Compilers (CS 421)
Axiomatic semantics Points to discuss: The assignment statement
Programming Languages and Compilers (CS 421)
Programming Languages 2nd edition Tucker and Noonan
Programming Languages and Compilers (CS 421)
Programming Languages and Compilers (CS 421)
Programming Languages and Compilers (CS 421)
Semantics In Text: Chapter 3.
Axiomatic Verification I
Predicate Transformers
Programming Languages and Compilers (CS 421)
Proofs of Correctness: An Introduction to Axiomatic Verification
Axiomatic Verification I
PZ03D - Program verification
Programming Languages and Compilers (CS 421)
Program correctness Axiomatic semantics
Programming Languages 2nd edition Tucker and Noonan
COP4020 Programming Languages
Programming Languages and Compilers (CS 421)
Presentation transcript:

Programming Languages and Compilers (CS 421) Sasa Misailovic 4110 SC, UIUC https://courses.engr.illinois.edu/cs421/fa2017/CS421A Based in part on slides by Mattox Beckman, as updated by Vikram Adve, Gul Agha, and Elsa L Gunter 5/29/2019

Axiomatic Semantics Also called Floyd-Hoare Logic Based on formal logic (first order predicate calculus) Axiomatic Semantics is a logical system built from axioms and inference rules Mainly suited to simple imperative programming languages 5/29/2019

Axiomatic Semantics Used to formally prove a property (post-condition) of the state (the values of the program variables) after the execution of program, assuming another property (pre-condition) of the state holds before execution 5/29/2019

Goal: Derive statements of form {P} C {Q} Axiomatic Semantics Goal: Derive statements of form {P} C {Q} P , Q logical statements about state, P precondition, Q postcondition, C program Example: {x > 1} x := x + 1 {x > 2} 5/29/2019

Axiomatic Semantics Approach: For each kind of language statement, give an axiom or inference rule stating how to derive assertions of form {P} C {Q} where C is a statement of that kind Compose axioms and inference rules to build proofs for complex programs 5/29/2019

Axiomatic Semantics An expression {P} C {Q} is a partial correctness statement For total correctness must also prove that C terminates (i.e. doesn’t run forever) Written: [P] C [Q] Will only consider partial correctness here 5/29/2019

Language We will give rules for simple imperative language <command> ::= <variable> := <term> | <command>; … ;<command> | if <expression> then <command> else <command> fi | while <expression> do <command> od Could add more features, like for-loops 5/29/2019

Substitution Notation: P[e/v] (sometimes P[v <- e]) Meaning: Replace every v in P by e Example: (x + 2) [y-1/x] = ((y – 1) + 2) 5/29/2019

The Assignment Rule {P [e/x] } x := e {P} Example: { ? } x := y {x = 2} 5/29/2019

The Assignment Rule {P [e/x] } x := e {P} Example: { _ = 2 } x := y { x = 2} 5/29/2019

The Assignment Rule {P [e/x] } x := e {P} Example: { y = 2 } x := y { x = 2} 5/29/2019

The Assignment Rule {y = 2} x := 2 {y = x} {P [e/x] } x := e {P} Examples: {y = 2} x := y {x = 2} {y = 2} x := 2 {y = x} {x + 1 = n + 1} x := x + 1 {x = n + 1} {2 = 2} x := 2 {x = 2} 5/29/2019

The Assignment Rule – Your Turn What is a valid precondition of x := x + y {x + y = w – x}? {(x + y) + y = w – (x + y)} x := x + y {x + y = w – x} ? 5/29/2019

The Assignment Rule – Your Turn What is a valid precondition of x := x + y {x + y = w – x}? {(x + y) + y = w – (x + y)} x := x + y {x + y = w – x} 5/29/2019

Precondition Strengthening P  P’ {P’} C {Q} {P} C {Q} Meaning: If we can show that P implies P’ (P P’) and we can show that {P’} C {Q}, then we know that {P} C {Q} P is stronger than P’ means P  P’ 5/29/2019

Precondition Strengthening Examples: x = 3  x < 7 {x < 7} x := x + 3 {x < 10} {x = 3} x := x + 3 {x < 10} True  2 = 2 {2 = 2} x:= 2 {x = 2} {True} x:= 2 {x = 2} x=n  x+1=n+1 {x+1=n+1} x:=x+1 {x=n+1} {x=n} x:=x+1 {x=n+1} 5/29/2019

Which Inferences Are Correct? {x > 0 & x < 5} x := x * x {x < 25} {x = 3} x := x * x {x < 25} {x * x < 25 } x := x * x {x < 25} 5/29/2019

Which Inferences Are Correct? {x > 0 & x < 5} x := x * x {x < 25} {x = 3} x := x * x {x < 25} {x * x < 25 } x := x * x {x < 25} 5/29/2019

{z = z & z = z} x := z {x = z & z = z} Sequencing {P} C1 {Q} {Q} C2 {R} {P} C1; C2 {R} Example: {z = z & z = z} x := z {x = z & z = z} {x = z & z = z} y := z {x = z & y = z} {z = z & z = z} x := z; y := z {x = z & y = z} 5/29/2019

{z = z & z = z} x := z {x = z & z = z} Sequencing {P} C1 {Q} {Q} C2 {R} {P} C1; C2 {R} Example: {z = z & z = z} x := z {x = z & z = z} {x = z & z = z} y := z {x = z & y = z} {z = z & z = z} x := z; y := z {x = z & y = z} 5/29/2019

Postcondition Weakening {P} C {Q’} Q’  Q {P} C {Q} Example: {z = z & z = z} x := z; y := z {x = z & y = z} (x = z & y = z)  (x = y) {z = z & z = z} x := z; y := z {x = y} 5/29/2019

P  P’ {P’} C {Q’} Q’  Q {P} C {Q} Rule of Consequence Logically equivalent to the combination of Precondition Strengthening and Postcondition Weakening Uses P  P’ and Q’  Q 5/29/2019

if x < 0 then y:= y-x else y:= y+x fi {y=a+|x|} If Then Else {P and B} C1 {Q} {P and (not B)} C2 {Q} {P} if B then C1 else C2 fi {Q} Example: Want {y=a} if x < 0 then y:= y-x else y:= y+x fi {y=a+|x|} Suffices to show: (1) {y=a&x<0} y:=y-x {y=a+|x|} and (4) {y=a&not(x<0)} y:=y+x {y=a+|x|} 5/29/2019

{y=a & x<0} y:=y-x {y=a+|x|} (3) (y=a & x<0) y-x=a+|x| (2) {y-x=a+|x|} y:=y-x {y=a+|x|} (1) {y=a & x<0} y:=y-x {y=a+|x|} (1) Reduces to (2) and (3) by Precondition Strengthening (2) Follows from assignment axiom (3) Because from algebra: x<0  |x| = -x 5/29/2019

{y=a & not(x<0)} y:=y+x {y=a+|x|} (6) (y=a & not(x<0))(y+x=a+|x|) (5) {y+x=a+|x|} y:=y+x {y=a+|x}} (4) {y=a & not(x<0)} y:=y+x {y=a+|x|} (4) Reduces to (5) and (6) by Precondition Strengthening (5) Follows from assignment axiom (6) Because not(x<0)  |x| = x 5/29/2019

If Then Else (1) {y=a & x<0} y:=y-x {y=a+|x|} . (4) {y=a & not(x<0)} y:=y+x {y=a+|x|} . {y=a} if x < 0 then y:= y-x else y:= y+x {y=a+|x|} By the IfThenElse rule 5/29/2019

We need a rule to be able to make assertions about while loops. Inference rule because we can only draw conclusions if we know something about the body Let’s start with: { ? } C { ? } { ? } while B do C od { P } 5/29/2019

While The loop may never be executed, so if we want P to hold after, it had better hold before, so let’s try: { ? } C { ? } { P } while B do C od { P } 5/29/2019

While If all we know is P when we enter the while loop, then we all we know when we enter the body is (P and B) If we need to know P when we finish the while loop, we had better know it when we finish the loop body: { P and B} C { P } { P } while B do C od { P } 5/29/2019

{ P } while B do C od { P and not B } We can strengthen the previous rule because we also know that when the loop is finished, not B also holds Final while rule: { P and B } C { P } { P } while B do C od { P and not B } 5/29/2019

{ P } while B do C od { P and not B } { P and B } C { P } { P } while B do C od { P and not B } P satisfying this rule is called a loop invariant because it must hold before and after each iteration of the loop 5/29/2019

While While rule generally needs to be used together with precondition strengthening and postcondition weakening There is NO algorithm for computing the correct P; it requires intuition and an understanding of why the program works 5/29/2019

All Rules on One Slide 5/29/2019

Counting up to n n := 10; x := 0; while (x < n) { x := x + 1 } Want to show: x >= n P ≡ x ≤ n 5/29/2019

Sum of numbers 1 to n P ≡ x = 1 + ... + y ∧ y ≤ n ∧ 0 ≤ n x := 0 while y < n { y := y + 1; x := x + y } Want to show: x = 1 + ... + n P ≡ x = 1 + ... + y ∧ y ≤ n ∧ 0 ≤ n

Fibonacci P ≡ y = fib z ∧ x = fib (z-1) ∧ z ≤ n ∧ 1 ≤ n x = 0; y = 1; while (z < n) { y := x + y; x := y – x; z := z + 1 } Want to show: y = fib n P ≡ y = fib z ∧ x = fib (z-1) ∧ z ≤ n ∧ 1 ≤ n

List Length P ≡ y + len x = len lst x = lst; y = 0 while (x ≠ []) { x := tl x; y := y + 1 } Want to show: y = len lst P ≡ y + len x = len lst

Example (Use of Loop Invariant in Full Proof) Let us prove {x>= 0 and x = a} fact := 1; while x > 0 do (fact := fact * x; x := x – 1) od {fact = a!} 5/29/2019

(P and not x > 0) => (fact = a!) Example We need to find a condition P that is true both before and after the loop is executed, and such that (P and not x > 0) => (fact = a!) 5/29/2019

Example First attempt: P = {a! = fact * (x!)} Motivation: What we want to compute: a! What we have computed: fact which is the sequential product of a down through (x + 1) What we still need to compute: x! 5/29/2019

Example By post-condition weakening suffices to show 1. {x>=0 and x = a} fact := 1; while x > 0 do (fact := fact * x; x := x –1) od {a! = fact * (x!) and not (x > 0)} And 2. a! = fact * (x!) and not (x > 0) => fact = a! 5/29/2019

Problem!! (Dead End) 2. a! = fact * (x!) and not (x > 0) => fact = a! Don’t know this if x < 0 !! Need to know that x = 0 when loop terminates Need a new loop invariant Try adding x >= 0 Then will have x = 0 when loop is done 5/29/2019

P  a! = fact * (x!) and x >=0 Example Second try, let us combine the two: P  a! = fact * (x!) and x >=0 We need to show: 1. {x>=0 and x = a} fact := 1; {P} while x > 0 do (fact := fact * x; x := x –1) od {P and not x > 0} And 2. P and not x > 0  fact = a!

Example For Part 1, by sequencing rule it suffices to show {x>= 0 and x = a} (*this was part 1 to prove*) fact := 1; while x > 0 do (fact := fact * x; x := x –1) od {a! = fact * (x!) and x >=0 and not (x>0)} For Part 1, by sequencing rule it suffices to show 3. {x>=0 and x = a} fact := 1 {a! = fact * (x!) and x >=0 } And 4. {a! = fact * (x!) and x >=0} while x > 0 do (fact := fact * x; x := x –1) od {a! = fact * (x!) and x >=0 and not (x > 0)}

Example (Part 3 – Assignment) Suffices to show that a! = fact * (x!) and x >= 0 holds before the while loop is entered (Part 4 – While Loop) And that if (a! = fact * (x!)) and x >= 0 and x > 0 holds before we execute the body of the loop, then (a! = fact * (x!)) and x >= 0 holds after we execute the body (part 4) 5/29/2019

Example (Part 3) By the assignment rule, we have {a! = 1 * (x!) and x >= 0} fact := 1 {a! = fact * (x!) and x >= 0} Therefore, to show (3), by precondition strengthening, it suffices to show (x>= 0 and x = a)  (a! = 1 * (x!) and x >= 0) It holds because x = a  x! = a! . So, we have that a! = fact * (x!) and x >= 0 holds at the start of the while loop!

Example To prove (Part 4): {a! = fact * (x!) and x >=0} while x > 0 do (fact := fact * x; x := x –1) od {a! = fact * (x!) and x >=0 and not (x > 0)} we need to show that (a! = fact * (x!)) and x >= 0 is a loop invariant We will use assignment rule, sequencing rule and precondition strengthening rule 5/29/2019

Example We look into the loop body: (fact := fact * x; x := x – 1) By the sequencing rule, we need to show 2 things: By the assignment rule, show {(a! = fact * (x!)) and x >= 0 and x > 0} fact = fact * x {Q} x := x – 1 {(a! = fact * (x!)) and x >= 0} 5/29/2019

Example We look into the loop body: (fact := fact * x; x := x – 1) By the sequencing rule, we need to show 2 things: By the assignment rule, show {(a! = fact * (x!)) and x >= 0 and x > 0} fact = fact * x {Q} From the assignment rule, we know: {(a! = fact * ((x-1)!)) and x – 1 >= 0} x := x – 1 {(a! = fact * (x!)) and x >= 0} 5/29/2019

{(a! = fact * ((x-1)!)) and x – 1 >= 0} Example We look into the loop body: (fact := fact * x; x := x – 1) By the sequencing rule, we need to show 2 things: By the assignment rule, show {(a! = fact * (x!)) and x >= 0 and x > 0} fact = fact * x {(a! = fact * ((x-1)!)) and x – 1 >= 0} From the assignment rule, we know: x := x – 1 {(a! = fact * (x!)) and x >= 0} 5/29/2019

Example By the assignment rule, we have that {(a! = (fact * x) * ((x-1)!)) and x – 1 >= 0} fact = fact * x {(a! = fact * ((x-1)!)) and x – 1 >= 0} By Precondition strengthening, it suffices to show that ((a! = fact * (x!)) and x >= 0 and x > 0)  ((a! = (fact * x) * ((x-1)!)) and x – 1 >= 0) From algebra we know that fact * x * (x – 1)! = fact * x! and (x > 0)  x – 1 >= 0 since x is an integer, so {(a! = fact * (x!)) and x >= 0 and x > 0}  5/29/2019

P  a! = fact * (x!) and x >=0 Example Second try, let us combine the two: P  a! = fact * (x!) and x >=0 We need to show: 1. {x>=0 and x = a} fact := 1; {P} while x > 0 do (fact := fact * x; x := x –1) od {P and not x > 0} And 2. P and not x > 0  fact = a! 

(a! = fact * (x!) and x >=0 and not (x > 0))  (fact = a!) Example For Part 2, we need (a! = fact * (x!) and x >=0 and not (x > 0))  (fact = a!) Since we know (x >=0 and not (x > 0))  (x = 0) so fact * (x!) = fact * (0!) And since from algebra we know that 0! = 1, fact * (0)! = fact * 1 = fact Therefore, we can prove: 5/29/2019

 Example This finishes the proof! We proved that (a! = fact * (x!)) and x >= 0 is the loop invariant We proved the sequence rule for the assignment and wile statements We applied postcondition weakening to prove the final predicate This finishes the proof! {x >= 0 and x = a} fact := 1; while x > 0 do (fact := fact * x; x := x – 1) od {fact = a!} 

More examples https://www.rise4fun.com/ Dafny Boogie Spec# Chalice Z3 5/29/2019

Course Objectives New programming paradigm Functional programming Environments and Closures Patterns of Recursion Continuation Passing Style Phases of an interpreter / compiler Lexing and parsing Type systems Interpretation Programming Language Semantics Lambda Calculus Operational Semantics Axiomatic Semantics 5/29/2019

Major Phases of a PicoML Interpreter Source Program Lex Tokens Parse Analyze + Transform Abstract Syntax Optimized IR (CPS) Interpreter Execution Semantic Analysis Program Run Types, Environment Translate Intermediate Representation (CPS)

Where to go from here? Analyze + Transform Lex Assembler Instruction Source Program Lex Optimized IR (CPS) Assembler Tokens Instruction Selection Parse Relocatable Object Code Abstract Syntax Unoptimized Machine-Specific Assembly Language Linker Instruction Optimize Machine Code Semantic Analysis Optimized Machine-Specific Assembly Language Environment Translate Emit code Intermediate Representation (CPS) Assembly Language Modified from “Modern Compiler Implementation in ML”, by Andrew Appel