From crocker%la.tis.com Thu, 01 Jun 89
To: info-hol@clover.ucdavis.edu
Subject: Re: Library for bitstrings
Date: Thu, 01 Jun 89 10:39:09 PDT
From: crocker%la.tis.com
Status: RO


This is in response to Tom's original note on the subject.

1. Tom commented that bitstrings are "Probably only of interest to
   hardware-verifiers)."

I disagree.  Bitstrings are critical to reasoning about microcode,
machine language programs, and any program that has to deal with
finite word lengths.  For example, bitstrings are needed when
reasoning about C programs that implement an operating system.  More
generally, formalization of the semantics of C (and many other
languages) requires a theory of bitstrings.


2. Tom writes:

   The decision that there should be no empty vector, I'm still unsure
   about.  But the basic idea behind this decision was that in hardware
   specifications it usually doesn't make sense to have an empty bit-vector.
   And, sometimes, specifications become a unnecessarily complicated when
   an empty vector is allowed (e.g. in defining an n-bit ripple-carry adder
   with extra circuitry to detect under/overflow for integer addition.
   When n=0, you have to generate some pretty ad-hoc "phoney" circuitry
   just to make the purely mathematical details work out).  The tools
   are therefore based on the type (*)vect of NON-EMPTY bit vectors, so that
   the "empty" bit-vector just doesn't arise.  If it turns out that this
   is a problem, the whole thing can be easily re-implemented based
   on (*)list.  Perhaps the library version should offer an option?

This is an interesting dilemma.  After working with bitstrings for
quite a while, I find I can see both sides of the issue.  I'd
generally favor a regular theory that includes zero length bitstrings,
but there are difficulties either way.


This may be a good time to bring up a point Tom and I discussed last
year.  (And I hope he is tolerant with my imperfect presentation and
fixes up my errors.)

It seems to me that it's possible to have a theory that doesn't
disclose whether bitstrings are defined from left to right, from right
to left, or some other way.  Begin by defining bitstrings in either
order.  Then define the APPEND function.  Then prove the following
theorem.

        Let f be any function over bitstrings which meets the
        following conditions:

        a) f("0") = a0
        b) f("1") = a1
        c) f(APPEND(x,y)) = op(f(x),f(y)), where op is associative

        Then f exists and is uniquely (and fully) determined.


Once this theorem is defined, it's possible to ignore whether
bitstrings are defined left to right or right to left.  Some
properties of bitstrings can then be defined by application of this
theorem, without resorting to induction proofs for each new property.
Here's a table of three examples.

        f               a0      a1      op      Comment

        LENGTH          1       1       +       The usual length function
        ONES            0       1       +       Number of ones in bitstring
        PARITY          0       1       XOR     Parity of bitstring



This approach is similar to using the same rules for information
hiding in theory design that are considered good form in program
design.  The only access to the theory of bitstrings should be via the
theorems provided from the package.


Steve

