this article we will not attempt to describe all the dierent possible choices of type theories. Instead we want to discuss the main underlying ideas, with a special focus on the use of type theory as the formalism for the description of theories including proofs

Abstract. This paper shows how classic inductive assertions can be used in conjunction with an operational semantics to prove partial correctness properties of programs. The method imposes only the proof obligations that would be produced by a verification condition generator but does not require the definition of a verification condition generation. The paper focuses on iterative programs but recursive programs are briefly discussed. Assertions are attached to the program by defining a predicate on states. This predicate is then “completed ” to an alleged invariant by the definition of a partial function defined in terms of the state transition function of the operational semantics. If this alleged invariant can be proved to be an invariant under the state transition function, it follows that the assertions are true every time they are encountered in execution and thus that the post-condition is true if reached from a state satisfying the pre-condition. But because of the manner in which the alleged invariant is defined, the verification conditions are sufficient to prove invariance. Indeed, the “natural ” proof generates the classical verification conditions as subgoals. The invariant function may be thought of as a state-based verification condition generator for the annotated program. The method allows standard inductive assertion style proofs to be constructed directly in an operational semantics setting. The technique is demonstrated by proving the partial correctness of simple bytecode programs with respect to a pre-existing operational model of the Java Virtual Machine. 1

Abstract not found

. Executable formal specification can allow engineers to test (or simulate) the specified system on concrete data before the system is implemented. This is beginning to gain acceptance and is just the formal analogue of the standard practice of building simulators in conventional programming languages such as C. A largely unexplored but potentially very useful next step is symbolic simulation, the "execution" of the formal specification on indeterminant data. With the right interface, this need not require much additional training of the engineers using the tool. It allows many tests to be collapsed into one. Furthermore, it familiarizes the working engineer with the abstractions and notation used in the design, thus allowing team members to speak clearly to one another. We illustrate these ideas with a formal specification of a simple computing machine in ACL2. We sketch some requirements on the interface, which we call a symbolic spreadsheet. 1 Introduction The use of formal methods...

We propose a grand challenge for the formal methods community: build and mechanically verify a practical embedded system, from transistors to software. We propose that each group within the formal methods community design and verify, by the methods appropriate to that group, an embedded system of their choice. The point is not to have just one integrated formal method or just one verified application, but to encourage groups to develop the techniques and methodologies necessary for system-level verification.

We describe a methodology for proving theorems mechanically about Java methods. The theorem prover used is the ACL2 system, an industrial-strength version of the Boyer-Moore theorem prover. An operational semantics for a substantial subset of the Java Virtual Machine (JVM) has been defined in ACL2. Theorems are proved about Java methods and classes by compiling them with javac and then proving the corresponding theorem about the JVM. Certain automatically applied strategies are implemented with rewrite rules (and other proof-guiding pragmas) in ACL2 “books” to control the theorem prover when operating on problems involving the JVM model. The Java Virtual Machine or JVM [27] is the basic abstraction Java [17] implementors are expected to respect. We speculate that the JVM is an appropriate level of abstraction at which to model Java programs with the intention of mechanically verifying their properties. The most complex features of the Java subset we handle – construction and initialization of new objects, synchronization, thread management, and virtual method invocation – are all supported directly and with full abstraction as single atomic instructions in the JVM. The complexity of verifying JVM bytecode program stems from the complexity of Java’s semantics, not

We argue that a practical way to apply formal methods to Java is to apply formal methods to the Java Virtual Machine (JVM) instead. A Java system can be proved correct by analyzing the bytecode produced for it. We believe that this clari es the semantic issues without introducing inappropriate complexity. We say \inappropriate" because we believe the complexity present in the JVM view of a Java class is inherent in the Java, when accurately modeled. If it is desired to model a subset of Java or to model \Java" with a slightly simpler semantics, that can be done by formalizing a suitable abstraction of the JVM. In this paper we support these contentions by surveying recent applications of the ACL2 theorem proving system to the JVM. In particular, we describe how ACL2 is used to formalize operational semantics, we describe several models of the JVM, and we describe proofs of theorems involving these models. We are using these models to explore a variety of Java issues from a formal perspective, including Java's bounded arithmetic, object manipulation via the heap, class inheritance, method resolution, singleand multi-threaded programming, synchronization via monitors in the heap, and properties of the bytecode veri er.

ACL2 is a first-order applicative programming language based on Common Lisp. It is also a mathematical logic for which a mechanical theoremprover has been implemented in the style of the Boyer-Moore theorem prover. The ACL2 system is used primarily in the modeling and verification of computer hardware and software, where the executability of the language allows models to be used as prototype designs or "simulators." To support efficient execution of certain kinds of models, especially models of microprocessors, ACL2 provides "single-threaded objects," structures with the usual "copy on write" applicative semantics but for which writes are implemented destructively. Syntactic restrictions insure consistency between the formal semantics and the implementation. The design of single-threaded objects has been influenced both by the need to make execution efficient and the need to make proofs about them simple. We discuss the issues. 1 Background "ACL2" stands for "A Computational Logic for...

We discuss an axiomatic description of a simple abstract machine similar to the Java Virtual Machine (JVM). Our model supports classes, with fields and bytecoded methods, and a representative sampling of JVM bytecodes for basic operations for both data and control. The GETFIELD and PUTFIELD instructions accurately model inheritance, as does the INVOKE-VIRTUAL instruction. Our model supports multiple threads, synchronized methods, and monitors. Our current model is inadequate or inaccurate

Permission is granted for noncommercial reproduction of the work for educational or research purposes. This copyright notice must be included in the reproduced paper. USENIX acknowledges all trademarks herein. An Executable Formal Java Virtual Machine Thread Model We discuss an axiomatic description of a simple abstract machine similar to the Java Virtual Machine (JVM). Our model supports classes, with fields and bytecoded methods, and a representative sampling of JVM bytecodes for basic operations for both data and control. The GETFIELD and PUTFIELD instructions accurately model inheritance, as does the INVOKE-VIRTUAL instruction. Our model supports multiple threads, synchronized methods, and monitors. Our current model is inadequate or inaccurate