david evans http www cs virginia edu evans
Download
Skip this Video
Download Presentation
David Evans cs.virginia/~evans

Loading in 2 Seconds...

play fullscreen
1 / 18

David Evans cs.virginia/~evans - PowerPoint PPT Presentation


  • 93 Views
  • Uploaded on

Lecture 19: Minding Ps & Qs: Axiomatic Semantics and Program Verification. David Evans http://www.cs.virginia.edu/~evans. It is easier to write an incorrect program than understand a correct one. Alan Perlis. CS655: Programming Languages University of Virginia Computer Science.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' David Evans cs.virginia/~evans' - kelvin


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
david evans http www cs virginia edu evans

Lecture 19: Minding Ps & Qs:

Axiomatic Semantics and Program Verification

David Evans

http://www.cs.virginia.edu/~evans

It is easier to write an incorrect program than understand a correct one.

Alan Perlis

CS655: Programming Languages

University of Virginia

Computer Science

operational semantics
Operational Semantics
  • Map to execution of a virtual machine
  • Depends on informal understanding of machine
  • Were able to prove that all programs in a language without loops terminate
  • Awkward notion of equivalence
  • Hard to prove properties about all possible executions of a program – need to simulate execution

CS 655: Lecture 19

static semantics
Static Semantics
  • Can prove properties about simple properties (type checking) easily
  • Cannot take into account any dynamic properties
    • Proofs must assume type of reference does not change throughout execution

CS 655: Lecture 19

axiomatic semantics
Axiomatic Semantics
  • Reason about programs using axioms (mathematical rules about program text fragments)
  • Depends on informal (almost formal) understanding of logic
    • Better than depending on informal understanding of Virtual Machine (Operational Semantics)
  • Allows reasoning about all possible executions
  • Can prove more interesting properties about programs than static semantics
    • Can deal with control flow, dynamic properties, etc.

CS 655: Lecture 19

floyd hoare rules
Floyd-Hoare Rules

pre-condition

post-condition

P { code fragment } Q

Partial correctness:

For all execution states which satisfy P, if the code fragment terminates, the resulting execution state satisfies Q.

Total correctness:

For all execution states which satisfy P, the code fragment terminates and the resulting execution state satisfies Q. (Sometimes people write: P [ code fragment ] Q.)

CS 655: Lecture 19

a simple example
A simple example

{ true } while true do x := 1 { 2 + 2 = 5 }

Partial correctness:

Yes! Since code doesn’t terminate,

any post-condition is satisfied.

Total correctness:

No! Since code doesn’t terminate,

no total correctness post-condition

could be satisfied.

CS 655: Lecture 19

a toy language algorel
A Toy Language: Algorel

Program ::= Statement

Statement ::=

Variable :=Expression

| Statement ; Statement

| while Pred doStatementend

Expression ::= Variable | IntLiteral

| Expression + Expression

| Expression*Expression

Pred ::= true | false | Expression <= Expression

CS 655: Lecture 19

assignment axiom
Assignment Axiom

P[e/x]

{x:=e side-effect-free(e) }

P

P is true after x:=e, iff P with e substituted for x was true before the assignment.

CS 655: Lecture 19

assignment example
Assignment Example

wp{ x := x + 1 } x = 3

P[e/x] {x:=e sef(e) }P

wp = (x = 3)[x + 1/x]

wp = ((x + 1)= 3)

wp = (x = 2)

CS 655: Lecture 19

weakest preconditions
Weakest Preconditions

P { S } Q

  • Given Q and S, what is the weakest P such that P { S }  Q

x = 2 { x := x + 1 } x = 3

  • Is there a stronger precondition?
  • Is there a weaker precondition?
  • Is there always a weakest precondition for any S and Q?

CS 655: Lecture 19

if axiom
If Axiom

side-effect-free (b)

  • (P b { s1 } Q)
  • (P b { s2 } Q)

P { if b then s1 else s2 } Q

CS 655: Lecture 19

if example
If Example

P

{ if (x < 3) then x := x + 1 else x := x – 1 }

x 3

CS 655: Lecture 19

if example1
If Example

side-effect-free (x < 3)

  • (P x < 3 {x := x + 1} x 3)
  • (P (x < 3) {x := x – 1} x 3)

P { if(x < 3) then x := x + 1 else x := x – 1} x 3

weakest-precondition: P = x  3  x  2

CS 655: Lecture 19

an algorel program fragment
An Algorel Program Fragment

% Pre-condition: ?

while n <= x do

n := n + 1;

result := result * n;

end

% Post-condition: result = x!

CS 655: Lecture 19

goal find weakest pre condition
Goal: find weakest pre-condition

P & x0 = x

{

while n <= x do

n := n + 1;

result := result * n;

end

}

result = x0!

Elevator speech

CS 655: Lecture 19

rule for while
Rule for while

P  Inv

 Inv { Pred }  Inv

 Inv & Pred { Statement } Inv

 (Inv &~Pred)  Q

 whilePreddoStatementend terminates

P { while Preddo Statement end} Q

CS 655: Lecture 19

what can go wrong
What can go wrong?
  • Invariant too weak
    • Can’t prove (Inv &~Pred)  Q
  • Invariant too strong
    • Can’t prove Inv & Pred { Statement } Inv
    • Can’t prove P  Inv

(for sufficiently weak P)

CS 655: Lecture 19

summary
Summary
  • Once you have the right invariant, proving partial correctness is tedious but easy
    • Computers can do this quickly
  • Picking the right invariant is hard and not well understood
    • Computers can do this slowly in special circumstances, often need help (from programmer or language designer)
  • Next time: Proof-Carrying Code
    • Can quickly and automatically prove interesting properties (type safety, memory safety, etc.) about arbitrary code if you are given the right invariants

CS 655: Lecture 19

ad