An Industrial Strength Prover for a Logic Based on

¢ ¡ Matt Kaufmann and

Personal use of this material is permitted. particular style of formal veri®cation that has shown consid- However, permission to reprint/republish this erable promise in recent years is the use of general-purpose material for advertising or promotional pur- automated reasoning systems to model systems and prove poses or for creating new collective works for properties of them. Every such reasoning system requires resale or redistribution to servers or lists, or considerable assistance from the user, which makes it im- to reuse any copyrighted component of this portant that the system provide convenient ways for the user work in other works must be obtained from the to interact with it.

IEEE. £ One state-of-the-art general-purpose automated reason- ing system is ACL2: ªA Computational Logic for Applica- AbstractÐACL2 is a re-implemented extended version tive Common Lisp.º A number of automated reasoning of Boyer and Moore's Nqthm and Kaufmann's Pc-Nqthm, systems now exist, as we discuss below (Subsection 1.1). In intended for large scale veri®cation projects. This paper this paper we describe ACL2's offerings to the user for con- deals primarily with how we scaled up Nqthm's logic to an venient ªindustrial-strengthº use. We begin in Section 2 with ªindustrial strengthº Ð namely, a a history of the ACL2 project. Next, Section 3 describes the large applicative subset of Common Lisp Ð while preserv- logic supported by ACL2, which has been designed for con- ing the use of total functions within the logic. This makes venient speci®cation and veri®cation. Section 4 discusses it possible to run formal models ef®ciently while keeping guards, which connect ACL2 to ef®cient execution in Com- the logic simple. We enumerate many other important fea- mon Lisp and provide a powerful speci®cation capability. tures of ACL2 and we brie¯y summarize two industrial We illustration the role of guards in Section 5. In Section 6 applications: a model of the Motorola CAP digital signal we discuss other important features of ACL2. In Section 7 processing chip and the proof of the correctness of the kernel we present two industrial applications. We conclude with of the ¯oating point division algorithm on the AMD5 ¤ 86 Section 8. microprocessor by Advanced Micro Devices, Inc. Index termsÐformal veri®cation, automatic theorem prov- 1.1. Brief Comparison with Other Theorem Provers ing, computational logic, partial functions, total functions, type checking, microcode veri®cation, ¯oating point divi- As we mentioned above, there are many other automated sion, digital signal processing reasoning systems besides ACL2 and its ancestors. Al- though it is beyond the scope of this paper to survey the ®eld or provide descriptions of other systems, we say a few words here in order to provide some context for our work. 1. Introduction Active research continues in automated reasoning in a number of areas. Here is an incomplete list. In each case we give one or two representative systems. Certainly the areas FORMAL VERIFICATION is the use of mathematical below contain considerable overlap.

techniques to verify properties of a system description. A © ¥ The work reported here was performed while the authors were em- Provers providing strong support for speci®cation of

ployed at Computational Logic, Inc. computing systems (see below) ¦ Matt Kaufmann is with Motorola @ Lakewood, P.O. Box 6000, MD

F52, Austin, TX 78762. E-mail: Matt [email protected]. © CTL model checkers [29, 11] § J Moore is with the Department of Computer Sciences, University of

Texas at Austin, Austin, TX 78712. E-mail: [email protected]. © Geometry provers [13] ¨ Manuscript received Oct. 25, 1996; revised Mar. 31, 1997 Recommended for acceptance by C. Heitmeyer and S.R. Faulk © First-order provers [28] For information on obtaining reprints of this article, please send e-mail to: [email protected], and reference IEEECS Log Number 104892.0 © Classical Mathematics [21], [41] © Constructive Mathematics [15, 16] systems, including a reasonably large set of references for

accomplishments using the systems. A few particular suc- © Provers with symbolic computation engines [14] cesses are described in [4, 5, 10, 22, 32, 26, 36, 38]. A

© Meta-theoretic systems [34] tutorial introduction to the systems may be found in [24]. Like Nqthm, ACL2 supports a Lisp-like, ®rst-order, Provers in the ®rst category are distinguished by the con- quanti®er-free mathematical logic based on recursively de- venience they offer for specifying computing systems. Cases ®ned total functions. Experience with the earlier systems could be made that each prover in the ®rst category has ca- supports the claim that such a logic is suf®ciently expressive pabilities in most of the other categories; conversely, some to permit one to address deep mathematical problems and re- provers in the other categories could be placed in this one. alistic veri®cation projects. The fact that the Nqthm logic is The ®rst category may be subdivided as follows. executable is also an important asset when using it to model

hardware and systems: the models can be exe- © Higher-order tactic-based provers, e.g., HOL [20] cuted as a means of corroborating their accuracy. Consider

© Higher-order heavily-automated provers, e.g., PVS for example [2] where an Nqthm model of the MC68020 [18] is corroborated against a fabricated chip by running 30,000 test vectors through the Nqthm model. © First-order heavily-automated provers, e.g., ACL2 Some of the largest formal veri®cation projects done so and Nqthm far have been carried out with Nqthm. We cite explicitly the

© CLI short stack [4], the design and fabrication of the FM9001 Provers integrated into program veri®cation systems, microprocessor [22], and the veri®cation of the Berkeley C e.g., Never/EVES [17] string library on top of the MC68020 microprocessor [10]. Again, space does not permit detailed comparisons here. The formal models in these projects are collectively several Bill Young's paper [42] in this Special Issue compares PVS hundred pages long and involve many functions. Despite and ACL2 on a particular example. ACL2's ancestral sys- such successes, Nqthm was not designed for these kinds of tem, Nqthm, is compared to NuPRL in [3]. It is extremely large-scale projects and it has several inadequacies. The dif®cult to compare two general-purpose theorem provers at most important inadequacy of Nqthm is its lack of theorem least in part because experienced users can dramatically af- proving power: if it would quickly settle every question fect system behavior by proper formulation of the problems. put to it, one could proceed more ef®ciently. While we are That said, other systems cited above support logics more always looking for better proof techniques (e.g., [33]), we

do not know how to build a signi®cantly more powerful and powerful than that of ACL2. On the other hand, ACL2's theorem prover encourages more reliance by the user on the automatic theorem prover for Nqthm's logic. Therefore, to system's automatic aspects. For users happy with an essen- ªscale upº Nqthm we focused on engineering issues. tially quanti®er-free, ®rst-order logic, we believe that ACL2 We decided that a good ®rst step would be to adopt as a offers more overall convenience for the type of reasoning logic the applicative subset of a commonly used program- required to model and prove properties of digital computing ming language, thereby gaining access to many ef®cient systems. In addition to the sophisticated inference engine execution platforms for models written in the logic and it provides, ACL2 provides extremely ef®cient evaluation, many program development (i.e., modeling) environments. allowing formal models often to serve as simulators for the We chose Common Lisp because of its expressiveness, ef®- systems described. This, in turn, provides some immedi- ciency and familiarity. Properly formulated Common Lisp ate proof-independent payoff, e.g., requirements testing and can execute at speeds comparable to C. code development. Additional reasons for ACL2's conve- Three guiding tenets of the ACL2 project have been (1) nience can be broadly lumped into the ªproof engineeringº to conform to all compliant Common Lisp implementations, considerations discussed in Section 6. (2) to add nothingto the logic that violates the understanding See the URL http://www-formal.stanford.edu/clt/ARS/- that the user's input can be submitted directly to a Common ars-db.html for a data base of automated reasoning systems, Lisp and then executed (in an environment where including brief descriptions and links to the home pages of suitable ACL2-speci®c macros and functions Ð the ACL2 the systems mentioned and many more. kernel Ð are de®ned), and (3) to use ACL2 as the imple- mentation language for the ACL2 system. 2. History The third tenet is akin to recoding Nqthm in the Nqthm logic, a task that we believe would produce unacceptably slow performance. Programming the ACL2 system in ACL2

ACL2 is a direct descendant of the Boyer-Moore sys- ¡ tem, Nqthm [8, 9], and its interactive enhancement, Pc- We emphasize the word ªsigni®cantlyº here because ACL2's theorem Nqthm [23]. See [7] for an introduction to the two ancestral prover is in fact more powerful than Nqthm in many ways. See Section 6. repeatedly forced us to extend the subset so that we could © Strings. ACL2 supports strings of characters, e.g., write acceptably ef®cient code. Several iterations of the the string constant "Arithmetic Overflow".

system were built. The current system consists of over 5 © megabytes of applicative source code, including documen- Symbols. Common Lisp provides a sophisticated tation. class of objects called ªsymbol constants.º Logi- The ®rst version of the system was written in the summer cally speaking, a symbol constant is an object con- and fall of 1989, by Boyer and Moore. As time went by, taining two strings: a package and a name. The Boyer's involvement decreased and Kaufmann's increased. symbol constant with package "MC68020" and Eventually Boyer decided he should no longer be considered name "EXEC" is written MC68020::EXEC. By con- a coauthor. ACL2 has been used in modeling and veri®ca- vention, one package is always selected as ªcur- tion projects within Computational Logic, Inc. (CLI), for rentº and its name need not be written. Thus, if several years. We released the ®rst public version of ACL2 "MC68020" is the current package, the symbol in September, 1995. See the URL http://www.cli.com. above may be more simply written as EXEC. Pack- ages may ªimportº symbols from other packages (al- 3. The ACL2 Logic though in ACL2 all importation must be done at the time a package is de®ned). If MC68020::EXEC is imported into the "STRING-LIB" package then The de®nition of Common Lisp used in our work has STRING-LIB::EXEC is in fact the same symbol as been [39, 40]. We have also closely studied [35]. MC68020::EXEC. The ACL2 logic is a ®rst-order, quanti®er-free logic of total recursive functions providing mathematical induction © Lists. ACL2 supports arbitrary ordered pairs of ACL2 on the ordinals up to ¢¡ and two extension principles: one objects, e.g., the list constant (X MC68020::X for recursive de®nition and one for ªencapsulation.º We ("Hello." (1 . 22/7))). sketch the logic here. 3.4. Axioms De®ning Other Primitive Function 3.1. Syntax Symbols The syntax of ACL2 is that of Common Lisp. Formally, Essentially all of the Common Lisp functions on the an ACL2 term is either a variable symbol, a quoted constant, above data types are axiomatized or de®ned as functions

or the application of an £ -ary function symbol or lambda

¤¦¥ ¥ ¤ or macros in ACL2. By ªCommon Lisp functionsº here

expression, , to £ terms, written ( ). We illustrate ¨§©§ £ we mean the programs speci®ed in [39] or [40] that are (i) the syntax for the primitive constants below. This formal applicative, (ii) not dependent on state, implicit parameters, syntax is extended by a facility for de®ning constant symbols or data types other than those in ACL2, and (iii) completely and macros. speci®ed, unambiguously, in a host-independent manner. Approximately 170 such functions are axiomatized. 3.2. Rules of Inference Common Lisp functions are partial; they are not de- ®ned for all possible inputs. But ACL2 functions are total. The rules of inference are those of Nqthm, namely propo- Roughly speaking, the logical function of a given name in sitional calculus with equality together with instantiation

¢¡ ACL2 is a completion of the Common Lisp function of the and mathematical induction up to . Two extension prin- same name obtained by adding some arbitrary but ªnaturalº ciples, recursive de®nition and encapsulation, are also pro- values on arguments outside the ªintended domainº of the vided; these are discussed in Subsection 3.6. Common Lisp function. ACL2 requires that every ACL2 3.3. Axioms for Primitive Data Types function symbol have a guard, which may be thought of as a predicate on the formals of the function describing the in- The following primitive data types are axiomatized. tended domain. But guards are entirely extra-logical: they

are not involved in the axioms de®ning functions. We dis- © ACL2 Numbers. The numbers consist of the ratio- cuss the role of guards when we explain the relation between nals and complex numbers with rational components. ACL2 and Common Lisp. Examples of numeric constants are -5, 22/7, and

#c(3 5)   (i.e., complex number ). 3.5. Axioms for Additions to Common Lisp © Character Objects. ACL2 supports 256 distinct characters, including Common Lisp's ªstandard char- To applicative Common Lisp we add four important new actersº such as the character constants #\A, #\a, features by introducing some new function symbols and #\,, #\Newline, and #\Space. appropriate axioms. © We add new multiple-valued function call and re- 3.6. Extension Principles turn primitives that are syntactically more restric- tive but similar to the Common Lisp primitives Finally, ACL2 has two extension principles: de®nition multiple-value-bind and values. Our and encapsulation. Both preserve the consistency of the ex- primitivesrequire a functionalways to return the same tended logic [25]. Indeed, the standard model of numbers number of values and to be called from contexts ªex- and lists can always be extended to include the newly intro- pectingº the appropriate number of values. These duced function symbols. (Inconsistency can thus be caused restrictions allow our multiple-valued functions to be only if the user adds a new axiom directly rather than via an implemented more ef®ciently than Common Lisp's extension principle.) (at least in the case of Gnu Common Lisp). Logically The encapsulation principle allows the user to introduce speaking, a vector of multiple values returned by a new function symbols that are constrained by axioms to have function is just a list of the values; but the implemen- certain properties. Consistency is ensured by requiring the tation is more ef®cient because the list is not actually user to exhibit witness functions satisfying the constraints. constructed. After a set of function symbols has been constrained, the witnesses used to establish consistency are irrelevant. The

© We add an explicit notion of ªstateº to allow the ACL2 only axioms about the new functions are those stating the programmer to accept input and cause output. The in- constraints. can then be proved about the con- put/output functions of Common Lisp are not in ACL2 strained functions and these theorems can be instantiated in because they are not applicative: they are dependent a higher-order way to derive analogous results about any on an implicit notion of the current state. An ACL2 functions satisfying the constraints. This is made possible state is an n-tuple containing, among other things, the by a derived rule of inference called functional instantiation ®le system and open input/output ªchannelsº to ®les. [6]. Primitive input/output functions are axiomatized to The name ªencapsulationº stems from the way the prin- take a state as an explicit parameter and to return a ciple is implemented. An encapsulation command is essen- new state as an explicit result (usually one of several tially a ªwrapperº around an admissible sequence of de®ni- results). Syntactic checks in the language ensure that tions and theorems. The wrapper allows one to mark certain the state is single-threaded, i.e., if a function takes of the de®nitions and theorems as ªlocal.º Local de®nitions state as an argument and calls a function that returns and theorems are not ªexportedº from the wrapper; non-local a new state, the new state (or more precisely, the ®- ones are exported. Within the local context established by nal descendant of it) must be returned. This gives an encapsulation, the constrained functions are (locally) de- rise to a well-de®ned notion of the ªcurrent stateº ®ned to be their witnesses and the constraints are (non-local) which is supplied to top-level calls of state-dependent theorems about those functions. Outside the encapsulation, ACL2 functions. The state returned by such calls the function symbols are unde®ned and the theorems appear becomes, by de®nition, the next current state. Be- as (consistent) axioms. This implementation makes encap- cause of these restrictions, the execution of a state- sulation very useful even when no new function symbols are dependent function need not (and does not) actually introduced because it allows large proofs to be structured. construct new state n-tuples but literally modi®es the See Section 6. underlying Common Lisp state. The de®nitional principle ensures consistency by requir- ing a proof that each de®ned function terminates. This is done, as in Nqthm, by the identi®cation of some ordinal © We add fast applicative arrays. These are imple- measure of the formals that decreases in recursion. In [8] mented, behind the scenes, with Common Lisp arrays we show (for Nqthm) that this ensures that one and only in a manner that always returns values in accordance one set-theoretic function satis®es the recursive de®nition, with our axioms and operates ef®ciently provided cer- and that proof carries over to the ACL2 case, with appro- tain programming disciplines are followed (namely, priate treatment of the non-uniqueness of any constrained they are used in a single-threaded way so that only functions used in the de®nition. the most recently updated version of an array is used). The form of an ACL2 function de®nition is as in Common There is no syntactic enforcement of the discipline; Lisp,

failure to follow it simply leads to inef®cient (but cor-

¤ ¡£¢¥¤§¦

rect) execution and warning messages. (defun ( ) (declare ) )

§ § § £ § § §

ACL2 extends Common Lisp's declare so as to permit the

©

We add fast applicative property lists in a manner speci®cation of a guard expression, ( ¨ ), as well as

§ § § similar to that for arrays. to permit the optional speci®cation of an£ ordinal measure and other hints. Some additional syntactic restrictions are know that car is a function: the form (equal (car 7) put on ¡£¢¥¤§¦ . These ensure that the Common Lisp version of (car 7)), which is an instance of the axiom (equal ¤ will execute ef®ciently and in accordance with claims we x x), might sometimes evaluate to nil in some Common make below. Roughly speaking, it is here that we enforce Lisps because the ®rst (car 7) might return 0 and the the syntactic notion that the current state is single threaded second might return 1. (by restricting the use of the variable named state) and ACL2 solves this problem by axiomatizing (car x) to ensure that multiple values are used appropriately. be a total function that returns nil outside the ªintended do- If the syntactic restrictions are met and the required ter- mainº described by the guard (or (consp x) (equal mination theorems can be proved, then x nil)). We claim our axioms describe Common Lisp's car when the argument to car satis®es our guard. Further-

Axiom. ¡¨§

¢¡ more, ACL2 provides a general means of verifying that such ¨¤£¥£¦£

( ) = ©  a situation obtains in the evaluation of a given expression is added as a new axiom. Observe that the axiom added is containing car. independent of the guard. While reading the rest of this section, the reader may wish to consider the possibilitythat our approach could be carried

4. The Relation Between ACL2 and Common out for other programming languages.  Although programs Lisp are commercially available for mainstream languages such as C that check for certain kinds of errors, we believe that no utilities match the capability for making arbitrary semantic Guards have no role in the logic. However, they are checks, statically, as we describe below for ACL2. Perhaps crucial to the relation of the logic to Common Lisp. an analogous approach for C would present an opportunity The implicit guards of Common Lisp allow great ef®- for integration of formal veri®cation into mainstream soft- ciency. There are implementations of Common Lisp, for ware development practice, lessening the need for dynamic example, Gnu Common Lisp, in which the performance of error-checking. the compiled code generated for arithmetic and list process- ing functions can be comparable to hand-coded C arithmetic 4.1. Gold Function Symbols and Terms and pointer manipulation. Exceptional execution ef®ciency on a wide variety of platforms, combined with clear applica- tive semantics when used properly, was one of the great To make precise the relation between ACL2 and Common attractions of basing the ACL2 logic on Common Lisp. Lisp, we de®ne two inter-related notions: that of a function Consider for example the primitive function car. Page symbol being ªgoldº; and that of a term being ªgoldº under 411 of [40] says that the argument to car ªmust beº a some hypothesis. (When no hypothesis is given, it is implic- cons or nil. On page 6 we learn ªIn places where it is itly t, the true hypothesis.) Roughly speaking, a function stated that so-and-so `must' or `must not' or `may not' be symbol is gold if, when its guard is true, the guards of all the case, then it `is an error' if the stated requirement is not subroutines encountered during evaluation are true of their

met.º On page 5 we learn that `it is an error' means that arguments. ªNo valid Common Lisp program should cause this situation © All ACL2 logic primitive function symbols are gold.

to occurº but that ªIf this situation occurs, the effects and

¤ ¡ results are completely unde®nedº and ªNo Common Lisp © A de®ned function with guard ¨ and body is gold implementation is required to detect such an error.º if every function symbol mentioned in ¨ is gold, the Thus, an implementation of the function car may as- ¤

term ¨ is gold, every function symbol besides that ¡ sume its actual is a cons or nil. By a suitable represen- is mentioned in ¡ is gold, and the term is gold under tation of data, the implementation of car can simply fetch ¨ . the contents of the memory location at which the actual is stored. No type checks are necessary. Of course, if car © Variables and quoted constants are gold terms.

7 

is applied to the results are unpredictable, possibly dam- ¡

©

 

The term (IF  ) is gold under if is gold 

aging to the runtime image, and usually implementation ¡ 

dependent. These aspects of Lisp make it dif®cult to debug under  , is gold under (AND ) and is gold 

compiled Lisp code. under (AND  (NOT )).

¤ ¤

This also raises problems with the direct embedding of © 

The term (  ), where is not IF and has

§ § §

applicative Common Lisp into a logic. The situation is far £

  

guard (¨ ) (where the are the formals

¤

§©§ §

worse than merely not knowing the value of (car 7). £

  of ) is gold under  provided each is gold under

We do not know that the value is an object in the logic: 

(car 7) might be  , for example. Worse still, we do not We thank one of the referees for posing this question.

 ¨  

 and (IMPLIES ( )) is a theorem. language and provide it to users via a stand-alone Common

£ §©§ The formula that must be prov§ ed is called the guard Lisp engine. The ACL2 theorem prover need not be present. conjecture for the subterm in question. A less obvious use of our claim is made inside the ACL2 theorem prover. In the course of theorem proving it is not We sometimes say a function or term is Common Lisp com- uncommon for ground subexpressions to arise, as by cer- pliant as a synonym for saying it is gold. We call the process tain instantiations of lemmas, case splits on enumerated do- of checking whether a function symbol or term is gold guard mains, the base cases of inductions, etc. Like Nqthm, ACL2 checking or guard veri®cation. has an interpreter for evaluating such ground expressions. The ACL2 completions of the Common Lisp primitives are 4.2. The Story Relating the Logic to Common Lisp built in. Runtime type checks are done by this interpreter,

e.g., to determine the value under the axioms of car ap-  We claim that if a function symbol of ACL2 is gold plied to a constant,  , the interpreter determines whether and a gold theorem has been proved about it, then every is a consp and then either uses Lisp's car or returns the execution of that function in any compliant Common Lisp default value nil. In this interpreter, calls of user-de®ned produces answers consistent with the theorem, provided the functions require recursive evaluation (and type-checking) arguments to the function satisfy the guard and no resource of the body, repeatedly. But when ACL2 evaluates a call errors (e.g., stack over¯ow) occur. Less precisely, gold of a gold function symbol, it can use direct Common Lisp ACL2 theorems describe the behavior of Common Lisp. computation if the guard evaluates to t. This claim can be made more precise as follows. We In both Nqthm and ACL2, the ªinterpreterº is imple- present the claim in a restrictive setting here for simplicity. mented by de®ning and compiling auxiliary Common Lisp Suppose ¤ is a function symbol of one argument de®ned in functions that do runtime type checking. Gold ACL2 func-

some certi®ed book (e.g., a ®le of admissible ACL2 de®ni- tions are generally compiled by ACL2 and do no type- ¤

tions and theorems), that the guard of ¤ is t, that is gold, checking. Thus, both the interpreter approach and the gold ¤ and that (equal ( ) t) is a (necessarily gold) theo- short-circuitenjoy the bene®ts of compilation; the ef®ciency rem of ACL2 proved in that book. Consider any Common difference is ACL2's avoidance of runtime type checking for Lisp compliant to [40] into which the ACL2 kernel has been certain subexpressions. This can make a substantial differ- loaded. Load the book into that Lisp. Let be a Com- ence in industrial-sized models.

mon Lisp object that is also an object of ACL2. Then the In summary, one important incremental effect of proving ¤ application in that Lisp of to returns t or else causes a that an ACL2 function symbol is gold is that subsequent resource error (e.g., stack over¯ow or memory exhaustion). applications of the function are more ef®ciently computed.

The essence of the proof of this claim is to observe that ¤ ( ) evaluates to t in the logic (because of the soundness 4.4. Guards as a Speci®cation Device of the logic), and the computation will at no step exercise a function symbol outside of its guarded domain (because ¤ Guards may also be used as type speci®cations. Gold is gold). Since the logic and Common Lisp agree inside the

¤ functions are ªwell-typed.º However, guards are much more guarded domain, the Common Lisp computation of ( ) expressive than conventional types, because they can be ar- returns t also.

¥ bitrary terms in the logic. Of course, ACL2 ªtype checkingº

A less restrictive alternative formulation is that if  is not decidable for this same reason. For some related work, is a gold theorem in some certi®ed book then any ACL2

¥ see [1].

instance of  evaluates to non-nil in any compliant If one attaches restrictive guards to one's functions and Common Lisp into which the ACL2 kernel and the book then proves the functions are gold, one obtains assurance have been loaded. that the functions are being exercised only on their intended domains. More precisely, one gains the knowledge that the 4.3. Guards and Ef®ciency computed value is provably equal to the function application in a weakened logical system in which the equality of each One obvious implication of the ªStoryº is that if one function application to its body is conditional on its guard has a formal model that has been proved Common Lisp being true. Nqthm provides no such assurance mechanism. compliant and one wishes to evaluate gold applications of the model, one can ignore the ACL2 theorem prover altogether, load the model into a compliant Common Lisp (containing 5. An Example the ACL2 kernel), and directly execute the model to obtain results consistent with the axioms. For example, one might In this section we illustrate some of the points just made build a gold simulator of a microprocessor or high-level about guards. 5.1. Admitting a De®nition 5.2. Some Theorems

Consider the problem of concatenating two lists. We We can prove the surprising theorem de®ne the function app to do this, as follows. Theorem. surprising-app-call (equal (app 7 8) (cons nil 8)) (defun app (x y) (declare (xargs :measure (m x) We will return to this surprising example later. :guard (true-listp x))) We can also prove the very useful and powerful uncon- (if (equal x nil) ditional equality stating that app is associative. y (cons (car x) (app (cdr x) y)))) Theorem. associativity-of-app (equal (app (app a b) c) (app a (app b c))) Ignore the declaration for the moment. Observe that the function terminates when x is nil and otherwise cdrs x in The proof takes advantage of the fact that car and cdr recursion. The intention is that x should always be a ªtrue return nil on non±cons arguments such as numbers. list,º i.e., a cons tree whose right-most branch terminates in If the guard for app infected the de®nition of app by

nil. If this function were applied to 7 and 8, in Common limiting its applicability to true lists, then app would not

Lisp, the result would be unpredictable: 7 ¡ nil, so we be unconditionallyassociative. Identifying suf®cient condi- recur on (cdr 7) and 8, but (cdr 7) is unde®ned in tions can be dif®cult. Since a appears as the ®rst argument Common Lisp. Replacing the (equal x nil) test with of a call of app in the conjecture, a must be a true list in (atom x) is ªmore sensibleº because then we know x is order to use the de®nition of app in that call. Similarly, b a cons when we cdr it. But Lisp programmers tend to use must be a true list. But (app a b) is also the ®rst argu-

the test above because it is more ef®cient than a type check ¢ ment of a call of app; so to use the de®nition of app on and is equivalent provided x is a true list. The declaration that call the system must be able to establish Ð either from of :guard (true-listp x) makes clear the intended a third hypothesis or by proof from the other hypotheses Ð domain. that (app a b) is a true list. Logically speaking, we must admit this function before In short, if the guard for a function infects the de®nitional we can reason about it. Logically speaking, the guard is axiom, theorems inherit that complexity compositionally irrelevant. We must show that a measure of the arguments and are weakened by encumbering hypotheses. Such weak- decreases in the recursion, no matter what x or y is used. ened theorems raise problems in three ways: (m x) A suitable measure, , is supplied by the user in the © they are harder for the user to state accurately; declaration; (m x) is de®ned (elsewhere) to be 0 if x is nil and otherwise to be one greater than the length of the © they are often harder to prove by induction because right-most branch of x. It is easy to show that the measure the induction hypothesis is weakened;

decreases in the recursion, i.e., that (m (cdr x)) £ (m

© x), when x ¡ nil. Intuitively, the recursion terminates they are harder to use subsequently because one must because in ACL2 cdr has been completed to return nil relieve their hypotheses. on non-conses, so when the recursion hits the atom at the bottom of the right-most branch it stops if that atom is nil Some of these same points are made in [27]. and otherwise it goes one more step, cdring the atom to The decision that guards will not affect the de®nitional produce a terminating nil. axioms thus has a far reaching effect. In fact, guards did play a logical role in earlier versions of ACL2, and After the function is admitted, the axiom we were driven to return to the Nqthm paradigm of total Axiom. functions because of the complexity that guards introduced (app x y) in some ªindustrial-strengthº proof efforts, particularly the = CAP project described later. (if (equal x nil) y 5.3. Compliance (cons (car x) (app (cdr x) y))) Returning now to the app example, we next ask what is added. Note that the axiom does not mention the guard. is its relationship to Common Lisp? We can prove that

¤ app is gold, i.e., Common Lisp compliant: Every function An equality test against a symbol can be done with a single address comparison and does not require a memory reference, as most type checks used in its de®nition (except app itself) is gold (they are do. all primitive) and when its body is evaluated, every guard encountered is true if the guard for app is true initially. The Of course, we must prove this theorem, but its proof is trivial latter condition can be expanded as follows. There are three given the unconditional associativity result! subroutines in the body of app that have non-trivial guards: We must also verify that it is gold, i.e., that the guard of car, cdr, and the recursive call of app. For the de®nition every call is satis®ed by the arguments of the call, in the con- to be gold, a theorem must be proved for each call of such text of the call. The two true-listp hypotheses have true a subroutine in the body of app. In particular, for each call guards. The three calls of app in which the ®rst argument we must prove that the guard of app, together with the tests is a variable symbol have guards requiring that the variable leading to the call, imply the guard of the call. To prove app in question, a or b appropriately, is a true-listp. These gold it therefore suf®ces to observe that if x is a non-nil guard conditions are trivial given the hypotheses. Finally, true list, then x must be a cons and the cdr is itself a true the guard condition for (app (app a b) c) generates list. the interesting guard condition that (app a b) is a true The extra-logical nature of guards is brought home by list when a and b are. the observation that we could de®ne another function, say xapp, that is analogous to app but contains no guard (i.e., 5.5. Separation of Concerns has a guard of t). The two functions are provably equiva- lent. But app is Common Lisp compliant and xapp is not Note how ACL2's treatment of guards separates con- because its guard conjectures cannot be proved. cerns. For theorem proving simplicity in the Nqthm tra- Because we know app is Common Lisp compliant, the dition ACL2 makes all functions total by completing the ªStoryº tells us any call of app that satis®es the guard exe- primitives with arbitrary but ªnaturalº default values. Func- cutes in accordance with the axioms of ACL2. Put another tions can be introduced into the logic without addressing the

way, if we wish to determine the value under our axioms of ¡

¡ question of whether they are compliant with Common Lisp.  (app  ), where and are constants, we can simply Their properties can be proved without concerning oneself execute the expression in Common Lisp, provided  is a true with questions of whether guards are satis®ed. Often this list. Thus, the user wishing to execute a formal model on allows the properties themselves to be more simply stated. concrete data satisfying the guard can run the model in Com- This allows the data base of rules to be less restrictive, more mon Lisp, provided the model has been proved compliant. powerful, and more easily applied. Nevertheless, non-gold Furthermore, because guards are gold terms, the suitability functions are evaluated under the axioms with Nqthm ef®- of the data can be determined by Common Lisp evaluation ciency. also. Once a system of ACL2 functions has been de®ned and its logical properties proved, one can move on to the ques- 5.4. Gold Theorems tion of Common Lisp compliance, either to gain execution ef®ciency in an ACL2 setting or in a stand-alone Common What about our theorems about the gold function app? Lisp, or to gain type assurance. Ef®ciency can be gained We have the surprising result that (equal (app 7 8) incrementally by doing guard veri®cation on the core sub- (cons nil 8)). Do we know that every compliant routines but not on the outlying checkers, preprocessors and Common Lisp will evaluate this to true? No! The theorem postprocessors typically involved in a big system. Further- is not gold. The guard for app is violated by 7. Nothing more, having proved certain functions gold one can stop and can be inferred about Common Lisp via our claim. Some settle for the corresponding ef®ciency or type assurance or Common Lisps may cause severe trouble if commanded to one can prove that the key properties proved are also gold. evaluate (app 7 8). Recall for example that one can carry out the following How about the associativity result for app? Can we sequence of steps: expect app to be unconditionally associative in Common Lisp? Again, the answer is no because the theorem is not © admit app as a function,

gold.

However, the following theorem is gold © prove it unconditionally associative,

Theorem. gold-associativity-of-app © prove it gold, i.e., Common Lisp compliant or well- (implies (and (true-listp a) typed, (true-listp b))

(equal (app (app a b) c) © trivially prove a restricted version of its associativity,

(app a (app b c)))) and then ¡

Here implies should be thought of as ªlazy,º i.e., (implies ¢

© £ £ prove that restricted version of associativity to be gold ) should be read as (if ¢ t), to be given proper treatment by our de®nition of ªgold.º or Common Lisp compliant. In versions of ACL2 predating Version 1.8, where guards ± the possibly complex environment necessary were part of the de®nitional equations, these issues were to certify a book need not be exported to the often intertwined so that it was impossible to address them reader's environment; separately. While this makes little difference in a setting as ± books are hierarchical and may include other simple as app and its associativity it makes a great deal of books, locally or otherwise; difference in models involving thousands of functions and properties. ± the reader may include many independently de- veloped books to create his or her environment; 6. Proof Engineering ± authors of books can install ªtheory invariantsº to help the readers manage the environments created by multiple books; We have argued that ACL2 is of ªindustrial strength.º Up to now our main argument has been its improved ef®ciency ± authors of books can document the de®nitions over Nqthm by virtue of being executable as Common Lisp, and theorems in a book so that the book's inclu- with special consideration for ef®cient execution of opera- sion updates the online documentation within tions involvingarrays, property lists, and state. We have also ACL2; indicated that a very expressive kind of type-correctness can ± consistency checks are done when books are be gained by ªguardº veri®cation, and yet this capability is included; separated from the logic proper so that proofs are not need- ± books carry certi®cates to help the community lessly hindered. Below we consider some strengths of ACL2 do version-control besides ef®ciency as a programming language: robustness, general features, maintainability, and proof support. © A ªprogramº mode that allows de®nition and exe- cution of functions without any proof burden being 6.1. Robustness imposed, and without any risk of unsoundness being introduced (as the prover does not know about ªpro- A notion of ªindustrial strengthº is the robustness of the gramº mode functions) tool. We have put considerable effort into making the pro- © A ªrealisticº collection of data types that includes gram bullet-proof, handling user errors graciously and with strings and (complex) rational numbers, with support appropriate messages. The interface is consistent, providing for reasoning about such data (e.g., a fully integrated the ability to submit de®nitions and theorems as well as the linear arithmetic decision procedure for the rationals) ability to execute applicative Lisp code ef®ciently. © Extensive capabilities for controlling the prover (see 6.2. Usability below)

© Common Lisp macros for ease of programming and Yet another notion of the ªindustrial strengthº of a tool is speci®cation without cluttering up the collection of its support for features that are crucial to get the job done. functions about which one needs to reason Here is a partial list of such features offered by ACL2. © Many useful programming primitives, including ef®- © Extensible on-line documentation that may be read at cient use of multiple values, arrays, property lists and the terminal, as well as through text and by way of ®le I/O hypertext (Emacs Info, HTML) © Common Lisp packages that support distinct name © Support for undoing back through a given command spaces as well as ªundoing an undoº © Mutually recursive de®nitions are supported © A notion of ªbooksº that allows independent devel- opment and inclusion of libraries of de®nitions and 6.3. Maintainability theorems: We also have found that the applicative style of program- ± books share the same underlying implementa- ming is amenable to maintenance, both for ®xing bugs and tion as encapsulation in that forms within them for implementing enhancements. Moreover, the subset of can be marked ªlocalº by the author of the book; Common Lisp that ACL2 supports has been suf®cient to ± the reader of a book only sees the non-local code all but the very lowest levels of the system (which are de®nitions and theorems; needed to implement some of the primitives). We believe that a Common Lisp program that is applicative and per- ± Linear arithmetic rules, together with a mech- haps even performs I/O is in fact an ACL2 program, or very anism to create rules for certain simple orders nearly so. other than the standard ªless-thanº order on the rationals 6.4. Proof Support ± ªCompound recognizer,º ªforward chaining,º ªtype prescription,º ªequivalence,º ªcongru- As with Nqthm and Pc-Nqthm, proofs of signi®cant the- ence,º and ªbuilt-in clauseº rules for ef®cient orems in ACL2 tend to require a serious effort on the part of automatic use of certain facts the user to prove appropriate supporting lemmas, primarily ± An improved ªmeta lemmaº facility that allows stored and used as (conditional) rewrite rules. However, such lemmas to be conditional (i.e., have hy- ACL2 offers many other ways by which the user can control potheses) the proof engine: ± Rules for use outside the simpli®er/rewriter: © As with Nqthm, a proof commentary in English that elimination and generalization assists users in debugging failed proofs Thus, we claim that ACL2 is industrial strength in its © As with Pc-Nqthm, an interactive loop for proof dis- ef®ciency, its consistent and robust interface, its array of covery that is extensible through ªmacrosº and has general features, its ease of maintenance, and the ¯exibility access to the full power of the theorem prover of its theorem prover.

© The capability to apply hints to individual subgoals 7. Industrial Applications © ªProof treeº displays to show the evolving structure of the proof in real time, and which also make it Of course, ultimately the test for whether a tool is ªindus- convenient to inspect failed proofs trial strengthº must be whether it can be used to do jobs of interest to industry. The ®rst two important applications of © Ef®cient handling of propositional logic, normally ACL2 support our claims that it is up to the task. These ap- through a clause generator that is much more ef®cient plications, summarized below, are discussed in more detail than Nqthm's, but also through a facility that inte- in [12] and [31], where we also detail the time and manpower grates ordered binary decision diagrams with rewrit- resources spent on the component tasks. ing

© A ªfunctional instantiationº facility that gives ACL2 7.1. Motorola CAP Digital Signal Processor (like Nqthm) some of the convenience of a higher- order logic without sacri®cing the simplicity of a ®rst Bishop Brock of CLI, working in collaboration with Mo- order logic torola, Inc., produced an executable formal ACL2 speci®- cation of the Motorola CAP [19], a digital signal proces- © A ªbreak-rewriteº facility, more sophisticated than sor designed by Motorola to execute a 1024 point complex that in Nqthm (or any other prover as far as we know), FFT in 131 microseconds. Every well-de®ned behavior of that allows proof-time debugging of the rewrite stack the CAP is modeled, including the pipeline, I/O, interrupts, breakpoints and traps (but excluding the hard and soft reset © A ªtheoryº mechanism that makes it easy to manipu- sequences). The CAP is much more complex than other late sets of rules, especially turning them on and off processors recently subjected to formal modeling, namely but also checking desired invariants on sets of rules the FM90001 [22], MC68020 [10], and AAMP5 [30]. In

© A ªforcingº mechanism that gives the prover permis- principle, a CAP single instructioncan simultaneously mod- sion to defer checking of hypotheses of speci®ed rules ify well over 100 registers. Brock's ACL2 model of the until the end of the ªmainº proof CAP is bit-accurate and cycle-accurate but runs faster than Motorola's SPW model. Furthermore, ACL2 can be used

© Support for a variety of types of rules (17), including to reason about the CAP model. ACL2 can compute the types supported by Nqthm. These include: symbolic effects of a complicated instruction in just a few seconds. With ACL2, Brock has proved that under suitable ± Conditional rewrite rules, which may be used conditions his model of the CAP is equivalent to a simpler not only to replace equals by equals but may also pipeline-free model. work with respect to user-de®ned equivalence Perhaps the most important aspect of the CAP work is (congruence) relations that with ACL2 it is possible to prove the correctness of CAP microcode programs. Because of the complexity of ¤ . Then two iterations of an ef®ciently computed variation

the instruction set, mechanical analysis of CAP microcode of the Newton-Raphson iteration are used to re®ne this ap-



programs is perhaps the only way to assure that the programs proximation so that the relative error is less than  . That

have certain properties. Brock used ACL2 to verify the approximation is then used to compute four ¯oating-point ¤

microcode produced by Motorola's assembler for several numbers whose sum is suf®ciently close to that when

¢¥¤¤£

CAP application programs, including a FIR ®lter and a peak it is rounded according to the result is the same as ¤ ®nding algorithm that uses the adder array as a chain of rounding instead. comparators. This work is discussed further in [12]. This algorithm is implemented in microcode; all of its Following the same approach used with Nqthm for the arithmetic computations use ¯oating point operations with MC68020 in [10], Brock con®gured ACL2 so as to make it directed rounding. To prove that the algorithm works as easy to symbolically execute a CAP microcode program on speci®ed we developed in ACL2 much ¯oating-point ªfolk- symbolic data. He then speci®ed and mechanically proved lore.º We also formalized the algorithm in ACL2 and then the total correctness of the microcode programs he consid- used ACL2 to check a fairly deep mathematical proof. A ered. It is possible (and often less labor intensive) to use the necessary step in our proof is to show that every intermedi- CAP model and ACL2 to prove weaker properties of mi- ate result ®ts in the (¯oating-point) resources allocated to it crocode, such as that no errors occur. We believe that once by AMD. a microcode engine such as the CAP is speci®ed in ACL2 How are the ªindustrial strengthº aspects of ACL2 used and a few application programs are mechanically veri®ed in this proof? The fact that ACL2 is executable is impor- for it, subsequent microcode applications can be done ªrou- tant. Our proof that two applications of Newton-Raphson tinely.º By ªroutinelyº here we mean that the technical iteration produce a suf®ciently accurate answer generalizes details of symbolic execution for that particular microcode away from the particular table used by AMD. We de®ne a can be managed by ACL2 and the effort of the veri®cation predicate that recognizes when a table contains suf®ciently task is dominated by consideration of the speci®cation and accurate 8-bit approximations to ¤ and prove that if the behavior of the given program. Newton-Raphson steps start from such a table, a correct Another important aspect of the ACL2 CAP model is answer is produced. The predicate is executable: given a that it executes CAP programs faster than Motorola's SPW concrete table, Common Lisp can determine by evaluation model. This makes it a convenient debugging tool. There whether it satis®es the predicate. Thus, to apply the result to are two reasons for its speed. One is that it is coded at a the actual AMD table, ACL2 merely executes the predicate somewhat higher level than the SPW model, i.e., arithmetic on the AMD table. in the model is arithmetic in Common Lisp, not (simulated) Other aspects of ACL2 that were crucial to this proof were combinational logic. The other is that Brock used strict encapsulation, macros and books. By using encapsulation guards that ensure that the model is type correct: registers and macros we were able conveniently to con®gure ACL2 contain data of appropriate size, addresses are legal, ob- temporarily to derive the key steps in the proof, without jects used as CAP machine states have the appropriate form, having to impose the same proof strategy on each key step. etc. All the functions in the CAP model are proved gold. By using books we were able to partition responsibility for Thus, the ACL2 CAP model can be compiled and faithfully various parts of the proof among the collaborators and then executed directly in Common Lisp. assemble the ®nal results. Subsequent to our proof of the ¯oating-point division microcode, David Russinoff used ACL2 to prove the cor- 7.2. AMD5 ¤ 86 Floating-Point Division

rectness of the AMD5 ¤ 86 's ¯oating-point square root mi- crocode [37]. In another test of the industrial applicabilityof ACL2, we collaborated with Tom Lynch of Advanced Micro Devices, Inc., to formalize and mechanically prove the correctness of 8. Conclusion the microcode for the kernel of the ¯oating pointdivisionop-

eration used on the AMD5 ¤ 86 microprocessor, AMD's ®rst ACL2 is a re-implemented extended version of Boyer

Pentium-class processor. In particular, in [31] we prove that and Moore's Nqthm and Kaufmann's Pc-Nqthm, intended ¤

when and are double extended precision ¯oating-point for large scale veri®cation projects. The ACL2 logic is an

¤ ¢¥¤¤£

¢¡

numbers ( ¡ ) and is a rounding mode specify- extension of a large applicative subset of Common Lisp,sup- ¦¥¨§ ©

ing a rounding style and target format of precision £ , porting a practical collection of data types, single threaded ¤

then the result of the algorithm is rounded according to states, I/O, multiple-valued functions, arrays and property

¢¥¤¤£ . lists. By careful design of the notion of guards, ACL2 al- As explained in detail in [31], the algorithm uses a ta- lows the elegant expression and proof of theorems in this ble to obtain an 8-bit approximation to the reciprocal of logic without many of the encumbrances of ªtype-likeº hy- potheses, while at the same time allowing functions in the tional Common Lisp. Ph.D. Thesis, University of logic to be related to Common Lisp in a way that allows Texas at Austin, 1993. Also available as Technical extremely ef®cient computation. Furthermore, the design Report 96, Computational Logic, Inc., Suite 290, allows for a clear separation of the problems of admission 1717 West Sixth Street, Austin, TX 78703. URL of logical de®nitions, proofs of simply stated properties, http://www.cli.com/. type-correctness, Common Lisp compliance and ef®cient execution. The design allows for incremental achievement [2] K. Albin. 68020 Model Validation Testing,CLI Note of these goals via proof, allowing the user to focus effort on 280, August 1993. the important aspects of the project. [3] D. Basin and M. Kaufmann, The Boyer-Moore ACL2 provides a wide variety of features supportiveof its Prover and Nuprl: An Experimental Comparison. industrial strength goals, including a rugged and extensively In: Proceedings of the First Workshop on ªLogical documented implementation, many convenient features for Frameworksº, Antibes, France, May 1990. constructing models and developing and structuring proofs, and good maintainability. Finally, we have demonstrated [4] W. R. Bevier, W. A. Hunt, J S. Moore, and W.D. that ACL2 can be used to tackle problems of importance to Young. Special Issue on System Veri®cation. Jour- industry. nal of Automated Reasoning, 5(4), 409±530, 1989. [5] W. R. Bevier and W. D. Young. Machine Checked ACKNOWLEDGMENTS Proofs of the Design of a Fault-Tolerant Circuit, Formal Aspects of Computing, Vol. 4, pp. 755± Without Bob Boyer's contributions, especially in the ini- 775, 1992. Also available as Technical Report 62, tial stages of ACL2 development, it is quite possible that Computational Logic, Inc., Suite 290, 1717 West ACL2 would never have been created. We are also es- Sixth Street, Austin, TX 78703, August, 1990 (URL pecially grateful to Bishop Brock for providing valuable http://www.cli.com/), and as NASA CR-182099, feedback based on his heavy use of ACL2 for many months. November, 1990. Bill Young improved and contributed tutorial material to the documentation. Art Flatau, Noah Friedman, and Laura [6] R. S. Boyer, D. Goldschlag, M. Kaufmann, and J Lawless contributed to technical aspects of the documenta- S. Moore. Functional Instantiation in First Order tion and provided useful feedback. We also acknowledge Logic. In Arti®cial Intelligence and Mathematical contributions from Bill Bevier, Alessandro Cimatti, Rich Theory of Computation: Papers in Honor of John Cohen, John Cowles, Warren Hunt, Jun Sawada, Bill Schel- McCarthy, Academic Press, 1991, pp. 7-26. ter, and Mike Smith. Finally, we are grateful for the utility provided by Gnu Emacs; in particular, Richard Stallman [7] Robert S. Boyer, Matt Kaufmann, and J Strother provided a Texinfo patch to assist in building the documen- Moore. The Boyer-Moore Theorem Prover and Its tation. We also thank the anonymous referees of this paper Interactive Enhancement. Computers and Mathe- who provided many valuable suggestions. matics with Applications, 29(2), 1995, pp. 27-62. This paper is an extended version the paper ªACL2: An [8] R. S. Boyer and J S. Moore. A ComputationalLogic, Industrial Strength Version of Nqthm,º which appeared in Academic Press: New York, 1979. Proceedings of the Eleventh Annual Conference on Com- puter Assurance (COMPASS-96), IEEE Computer Society [9] R. S. Boyer and J S. Moore. A Computational Logic Press, pp. 23±34, June, 1996. Handbook, Academic Press: New York, 1988. The work reported here was supported in part at Com- putational Logic, Inc., by the Advanced Research Projects [10] R. S. Boyer and Y. Yu, Automated Correctness Agency, ARPA Order D245, under Contract No. N66001- Proofs of Machine Code Programs for a Commer- 95-C-8634; ARPA Order 7406, and the Of®ce of Naval Re- cial Microprocessor. In D. Kapur, editor, Automated search, under Contract No. N00014-94-C-0193. The views Deduction ± CADE-11, Lecture Notes in Computer and conclusions contained in this document are those of the Science 607, Springer-Verlag, 416±430, 1992. authors and should not be interpreted as representing the of- [11] R. K. Brayton, G. D. Hachtel, A. Sangiovanni- ®cial policies, either expressed or implied, of Computational Vincentelli,F. Somenzi, A. Aziz, S.-T. Cheng, S. Ed- Logic, Inc. or the United States Government. wards, S. Khatri, Y. Kukimoto, A. Pardo, S. Qadeer, R. K. Ranjan, S. Sarwary, T. R. Shiple, G. Swamy, References T. Villa. VIS: A system for Veri®cation and Synthe- sis. 8th Intl. Conf. on Computer-Aided Veri®cation, [1] R. L. Akers. Strong Static Type Checking for Func- July, 1996. [12] B. Brock, M. Kaufmann and J S. Moore. ACL2 Technical report 19, Computational Logic, Inc., Theorems about Commercial Microprocessors. In May, 1988. URL http://www.cli.com/. M. Srivas and A. Camilleri, editors, in Computer-Aided Design (FMCAD'96), Springer- [24] M. Kaufmann and P. Pecchiari. Interaction with the Verlag, November 1996 (to appear). Boyer-Moore Theorem Prover: A Tutorial Study Using the Arithmetic-Geometric Mean Theorem. [13] S.-C. Chou, Mechanical Geometry Theorem Prov- Journal of Automated Reasoning 16, no. 1-2 (1996) ing, D. Reidel Publishing Co., Dordrecht, Holland, 181-222. 1988. [25] M. Kaufmann and J S. Moore, High-Level [14] E. M. Clarke and X. Zhao. Analytica: A theorem Correctness of ACL2: A Story (DRAFT), prover for Mathematica. The Journal of Mathemat- URL ftp://ftp.cli.com/pub/acl2/v1-8/acl2-sources/- ica, 3(1), pp. 56±71,Winter 1993. reports/story.txt, September, 1995. Revision in preparation. [15] R. L. Constable, et al., Implementing Mathematics with the Nuprl Proof Development System, Prentice [26] K. Kunen. A Ramsey Theorem in Boyer-Moore Hall, 1986. Logic, Journal of Automated Reasoning, 15(2) Oc- tober, 1995. [16] C. Cornes, J. Courant, J.-C. Filliatre, G. Huet, P. Manoury, et al. The Coq Proof Assistant, Ref- [27] L. Lamport, Types are Not Harmless, http://www.- erence Manual, Version 5.10. RT-0177, INRIA, B.P. research.digital.com/SRC/tla/tla.html, July, 1995. 105, 78153 Le Chesnay Cedex, France. [28] W. McCune. Otter 3.0 Reference Manual and [17] D. Craigen, S. Kromodimoeljo, I. Meisels, B. Pase, Guide. Report ANl-94/6, Argonne National Lab- M. Saaltink. EVES: An Overview. Odyssey Re- oratory (1994). search Center, ORA Conference Paper CP-91-5402- [29] Kenneth L. McMillan. Symbolic Model Checking. 43, March, 1991. Kluwer Academic Publishers, 1993. [18] J. Crow, S. Owre, J. Rushby, N. Shankar, and M. Sri- [30] S. P. Miller and M. Srivas. Formal Veri®cation of vas. A Tutorial Introduction to PVS, presented at the AAMP5 Microprocessor: A Case Study in the Workshop on Industrial-Strength Formal Speci®ca- IndustrialUse of Formal Methods, in Proceedings of tion Techniques, Boca Raton, FL, April 1995 (see WIFT '95: Workshop on Industrial-StrengthFormal http://www.csl.sri.com/pvs.html). Speci®cation Techniques, IEEECS, April, 1995, pp. [19] S. Gilfeather, J. Gehman, and C. Harrison. Architec- 2±16. ture of a Complex Arithmetic Processor for Com- [31] J S. Moore, T. Lynch, and M. Kaufmann. A municationSignal Processing. In SPIE Proceedings, Mechanically Checked Proof of the Correctness of International Symposium on Optics, Imaging, and the Kernel of the AMD5 ¤ 86 Floating Point Division Instrumentation,2296 Advanced Signal Processing: Algorithm, March, 1996 (submitted). URL http://-

Algorithms, Architectures, and Implementations V, devil.ece.utexas.edu:80/ lynch/divide/divide.html. 624±625, July, 1994. [32] J S. Moore. A Formal Model of Asynchronous Com- [20] M. J. C. Gordon and T. F. Melham (editors). In- munication and Its Use in Mechanically Verifying a troduction to HOL: A Theorem Proving Environ- Biphase Mark Protocol, Formal Aspects of Comput- ment for Higher-Order Logic. Cambridge Univer- ing 6(1), 60±91, 1994. sity Press, 1993. [33] J S. Moore. Introductionto the OBDD Algorithmfor [21] W. M. Farmer, J. D. Guttman, and F. J. Thayer. IMPS: the ATP Community, Journal of Automated Reason- An Interactive Mathematical Proof System. Journal ing 12, 33±45, 1994. of Automated Reasoning, 11(2), 213±248, 1993. [34] L. C. Paulson, Isabelle: A Generic Theorem Prover, [22] W. A. Hunt, Jr. and B. Brock. A Formal HDL and Springer-Verlag LNCS 828, 1994. its use in the FM9001 Veri®cation. Proceedings of the Royal Society, 1992. [35] K. M. Pitman et al. draft proposed American Na- tional Standard for Information Systems Ð Pro- [23] M. Kaufmann. A User's Manual for an Interactive gramming Language Ð Common Lisp; X3J13/93- Enhancement to the Boyer-Moore Theorem Prover, 102. Global Engineering Documents, Inc., 1994. [36] D. M. Russinoff. A Mechanical Proof of Quadratic Reciprocity. Journal of Automated Reasoning, 8(1), 3±21, 1992. [37] D. Russinoff, A Mechanically Checked Proof

of Correctness of the AMD5 ¤ 86 Floating-Point Square Root Microcode, http://www.onr.com/user/- russ/david/fsqrt.html, February, 1997. [38] N. Shankar. Metamathematics, Machines, and Godel'È s Proof, Cambridge University press, 1994. [39] G. L. Steele Jr. Common LISP: The Language, Dig- ital Press: Bedford, MA, 1984. [40] G. L. Steele, Jr. , Second Edition. Digital Press, 30 North Avenue, Burlington, MA 01803, 1990. [41] A. Trybulec. Built-in Concepts. Journal of Formal- ized Mathematics, Axiomatics, 1989. [42] W. D. Young, Comparing Veri®cation Systems: In- teractive Consistency in ACL2, IEEE Trans. Soft- ware Engineering, [this issue].

Matt Kaufmann was trained as a mathematical logician at the University of Wisconsin, receiving his PhD in mathe- matics there in 1978 after receiving his bachelor's degree at

MIT in 1973. His ®rst career led to 20 research papers in set-theoretic model theory, primarily while on the the math- ematics faculty at Purdue University. He then migrated into computer science, ®rst focusing on functional program- ming in a research position at Burroughs Corp. and then working for several years at Computational Logic, Inc. on general-purpose automated reasoning and applications. Dr. Kaufmann joined Motorola, Inc. in August, 1995, where he currently works on formal veri®cation of hardware.

J Strother Moore received his PhD degree from the University of Edinburgh in 1973 and his BS degree from the Masachusetts Institute of Technology in 1970. He holds the Admiral B.R. Inman Centennial Chair in ComputingTheory at the University of Texas at Austin. He is the author of many books and papers on automated theorem proving and mechanical veri®cation of computing systems. His most recent book is Piton: A Mechanically Veri®ed Assembly- Level Language (Kluwer, 1996). Along with Bob Boyer he is a co-author of the Boyer-Moore theorem prover and the Boyer-Moore fast string searching algorithm. He and Bob Boyer were awarded the 1991 Current Prize in Automatic Theorem Proving by the American Mathematical Society. Moore is a Fellow of the American Association for Arti®cial Intelligence.