Results 1  10
of
18
Proofassistants using Dependent Type Systems
, 2001
"... 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

Cited by 47 (4 self)
 Add to MetaCart
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
Inductive assertions and operational semantics
 CHARME 2003. Volume 2860 of LNCS., SpringerVerlag
, 2003
"... 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 th ..."
Abstract

Cited by 25 (7 self)
 Add to MetaCart
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 postcondition is true if reached from a state satisfying the precondition. 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 statebased 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 preexisting operational model of the Java Virtual Machine. 1
Symbolic Simulation: an ACL2 Approach
 Proceedings of the Second International Conference on Formal Methods in ComputerAided Design (FMCAD'98), volume LNCS 1522
, 1998
"... . 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 languag ..."
Abstract

Cited by 22 (1 self)
 Add to MetaCart
. 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...
A Grand Challenge Proposal for Formal Methods: A Verified Stack
"... 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 ..."
Abstract

Cited by 20 (1 self)
 Add to MetaCart
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 systemlevel verification.
Proving theorems about Java and the JVM with ACL2
 Models, Algebras and Logic of Engineering Software
, 2003
"... We describe a methodology for proving theorems mechanically about Java methods. The theorem prover used is the ACL2 system, an industrialstrength version of the BoyerMoore theorem prover. An operational semantics for a substantial subset of the Java Virtual Machine (JVM) has been defined in ACL2. ..."
Abstract

Cited by 18 (9 self)
 Add to MetaCart
We describe a methodology for proving theorems mechanically about Java methods. The theorem prover used is the ACL2 system, an industrialstrength version of the BoyerMoore 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 proofguiding 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
Formal Models of Java at the JVM Level A Survey from the ACL2 Perspective
 In Proc. Workshop on Formal Techniques for Java Programs, in association with ECOOP
, 2001
"... 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 compl ..."
Abstract

Cited by 14 (1 self)
 Add to MetaCart
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 multithreaded programming, synchronization via monitors in the heap, and properties of the bytecode veri er.
SingleThreaded Objects in ACL2
 Practical Aspects of Declarative Languages (PADL), volume 2257 of LNCS
, 1999
"... ACL2 is a firstorder 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 BoyerMoore theorem prover. The ACL2 system is used primarily in the modeling and verification of computer hardwa ..."
Abstract

Cited by 10 (2 self)
 Add to MetaCart
ACL2 is a firstorder 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 BoyerMoore 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 "singlethreaded 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 singlethreaded 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...
An Executable Formal Java Virtual Machine Thread Model
, 2001
"... 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 instru ..."
Abstract

Cited by 6 (0 self)
 Add to MetaCart
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 INVOKEVIRTUAL instruction. Our model supports multiple threads, synchronized methods, and monitors. Our current model is inadequate or inaccurate
Using Eternity Variables to Specify and Prove a Serializable Database Interface
 Sci. Comput. Program
, 2003
"... Eternity variables are introduced to specify and verify serializability of transactions of a distributed database. Eternity variables are a new kind of auxiliary variables. They do not occur in the implementation but are used in specification and verification. Elsewhere it has been proved that et ..."
Abstract

Cited by 5 (4 self)
 Add to MetaCart
Eternity variables are introduced to specify and verify serializability of transactions of a distributed database. Eternity variables are a new kind of auxiliary variables. They do not occur in the implementation but are used in specification and verification. Elsewhere it has been proved that eternity variables in combination with history variables are semantically complete for proving refinement relations.