Cse 3341 03 winter 2008 introduction to program verification february 5
1 / 23

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

  • Uploaded on

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.
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 2008 introduction to program verification february 5

CSE 3341.03 Winter 2008Introduction to Program VerificationFebruary 5

calculating with simplify

Review the simplify algorithm
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
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
how do we enter rules?

|: theory(file).

looks for a file named file.simp

|: theory('file.simp').


|: assert(( rule )).

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

Playing with simplify
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 ?


  • 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

  • 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
conditional example

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

|: 2*3.

2*3 ->>


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

Developing rules to get a proof
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 ->>


    |: x*0*y.

    x*y*0 ->>


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


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

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





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


Ch 5 1 abstract data types
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
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)

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

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

A very simple verification scenario
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 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
    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
    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)


    • a new ADT: queues

    • Exercise 5.3 --

      (a) and (b)