Loading in 5 sec....

CSE 3341.03 Winter 2008 Introduction to Program Verification February 5PowerPoint Presentation

CSE 3341.03 Winter 2008 Introduction to Program Verification February 5

- 69 Views
- Uploaded on

Download Presentation
## PowerPoint Slideshow about ' CSE 3341.03 Winter 2008 Introduction to Program Verification February 5' - garrison-fisher

**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

### CSE 3341.03 Winter 2008Introduction to Program VerificationFebruary 5

calculating with simplify

review the simplify algorithm

- simplify(Expr) = Result
if path_arg(Path, Expr) = Lhs,

% (there is a path in Expr to the sub-expression LHS)

and Lhs ->> Rhs, and

Modified = change_path_arg(Path, Expr, Rhs), and

Result = simplify(Modified)

- otherwisesimplify(Expr) = Expr.

in English --

- Result is the result of simplifying Expr if there is a path in Expr to a subterm Lhs,
and there is a rule that

Lhs ->> Rhs, and Modified is the term Expr with the Lhs subterm replaced by Rhs,

otherwiseResult is the input Expr

- simplify is an interpreter for "rewrite programs" (rules)

how do we enter rules?

|: theory(file).

looks for a file named file.simp

|: theory('file.simp').

or

|: assert(( rule )).

adds the rule at the end of the current list of rules

playing with simplify

indigo 301 % simplify

Version 1.4.2SWI, January 6, 2007

|:x > 0 implies a+a=a*2.

x>0 implies a+a=a*2 ->>

0<x implies a+a=a*2

Can we simplify further?

- try using a theory?
- trace ?

review:

- use simplify to do calculations on abstract datatypes - symbolically
- we represent everything by expressions (terms) — not objects
- example: calculate on stacks, using expressions to represent the stack objects

- evaluation of expressions is symbolic
- hence general: X-X ->> 0 means that X-X = 0 for all (symbolic) values of X.

conditional rules

- conditional rules evaluate relations and numerical expressions
- left ->> right :- condition applies if condition can be shown to simplify to true,
- X > Y ->> true :- X > Y.condition is true if X, Y are numbers and X is less than Y.
- conditional rules use a built-in evaluator, assigned, to evaluate functions in numerical expressions
- type information such as integer(X)can be used in a conditional rule.

conditional example

|:assert((M*N ->> Product :- Product assigned M*N)).

|: 2*3.

2*3 ->>

6

- Check use of assigned in /cs/course/3341/arithmetic.simp.

developing rules to get a proof

- exercise 4.1
- |:(a + b = b + a) implies a < b < a ->> false
- find a general rule to complete the proof.
- (replace arithmetic variables (lower-case) with pattern (upper-case) variables)

- exercise 4.3, page 12.
|: assert((0*X ->> 0)).

|: x*y*0.

x*y*0 ->>

0

|: x*0*y.

x*y*0 ->>

0

- reconstruct the rules which achieve the simplifications in Sec. 4.4

4.4

|:2*q+q*((a+8-a)-7) + q.

2*q+q* (8-7)+q

2*q+q*1+q

2*q+q+q

2*q+q*2

q*4

2*q+q* (a+8-a-7)+q ->>

q*4

Ch. 5.1: abstract data types

- now have the tools for verifying some algebraic calculations
- given the right theory file , we can do symbolic calculation on abstract datatypes
- ADTs are characterized by interrelated equations
"if it quacks like a duck . . ."

Leibnitz law ?

start with stacks

- push makes a new stack out of a stack argument and a data item
- pop makes a new smaller stack from a stack argument
- topextracts a data item from a stack
- stacks are actually isomorphic to a simple kind of list
- (CONS X List) = add X to the front of List = push X on the stack List

- specific stacks (constants) represented by expressions using push
- example: push(z, push(b, nil))
- push is the constructor for this datatype.

- stacks are actually isomorphic to a simple kind of list
- treat these as functors of terms
- push(data, stack)

stack computers

- examples:
- HP calculators
a stack computer will have stack operations or functions defined frompush, pop, and top

- languages: Forth, Factor
- Java VM -- see exercise 5.3 examples on p. 49

- HP calculators

- verification scenario:
evaluate an ADT expression

context: ADT defined by axioms in the form of identities

method: input ADT axioms and definitions to the simplify tool in the form of simplification rules; input an expression to be checked and see if it simplifies to the expected result.

background: mathematical simplification rules.The correctness of the evaluation is relative to the assumed correctness of the simplification rules and the correctness of the ADT axioms and definitions.

stack calculations

- stack function definitions are equations,
turn them into rewrite rules and use them to do symbolic calculation on stacks

- definitions of plus, times, etc. describe a stack-based arithmetic calculator

unspecified implementation

- Example: over(S) = push(top(pop(S)), S)
- What does over(S) do?
does it really work by popping S, and pushing the top element of this new stack onto the original S?

- implementation is not specified
(that's why the datatype is abstract)

- what happens if we do an illegal operation?
e. g. pop(pop(push(a, nil)))

- can we use simplify to detect illegal operations?

a very simple verification scenario

- prove (by symbolic calculation) that a certain sequence of operations on an abstract datatype computes a particular mathematical function.
- doubling example:
- |: theory('stack.simp').
- |: plus(dup(push(a, nil))).
- plus(dup(push(a,nil))) ->>
- push(a+a,nil)

correctness relies on correctness? No, theory (.simp) files are general

- correctness of our verification scenario for expression evaluation rests on correctness of theory files
- doesn't this invalidate the whole idea of verification?

- should be highly re-usable
- theories become quickly "bug-free"
- much easier to check than code

- evolve through use to become more comprehensive

verifying a Java stack machine program

- what does [Ingram, 1997] refer to?
- what does the manual tell you about a bytecode?
pop=87 Stack: ..., VAL -> ...

pop2=88 Stack: ..., VAL1, VAL2 -> ...

dup=89 Stack: ..., V -> ..., V, V

- what would a verification scenario for the JVM look like?

JVM scenario

- title: verify JVM bytecode sequence
- method: input bytecode definitions as rewrite rules,
input bytecode sequence, perhaps as a list [. . , . . . . . ] and initial stack (as an expression) to simplify

confirm the simplification yields desired result.

- background: stack axioms, stack operation definitions, and perhaps theorems; additional rewrite rules for processing a list (see Forth exercise)

queues

- a new ADT: queues
- Exercise 5.3 --
(a) and (b)

Download Presentation

Connecting to Server..