1 / 23

CSE 3341.03 Winter 2008 Introduction to Program Verification February 5

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

garrison-fisher
Télécharger la présentation

CSE 3341.03 Winter 2008 Introduction to Program Verification February 5

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CSE 3341.03 Winter 2008Introduction to Program VerificationFebruary 5 calculating with simplify

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

  3. 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)

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

  5. 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 ?

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

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

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

  9. 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)

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

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

  12. 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 ?

  13. 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. • treat these as functors of terms • push(data, stack)

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

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

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

  17. 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)

  18. what happens if we do an illegal operation? e. g. pop(pop(push(a, nil))) • can we use simplify to detect illegal operations?

  19. 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)

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

  21. 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?

  22. 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)

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

More Related