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

1 / 23

CSE 3341.03 Winter 2008 Introduction to Program Verification February 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

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

CSE 3341.03 Winter 2008 Introduction to Program Verification February 5

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

## 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 ?

• 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.

• 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.3examples on p. 49

• verification scenario:

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?

• correctness of our verification scenario for expression evaluation rests on correctness of theory files

• doesn't this invalidate the whole idea of verification?

• No, theory (.simp) files are general

• 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)