Semantic foundations for typed assembly languages

Ahmed, Amal; Appel, Andrew W.; Richards, Christopher D.; Swadi, Kedar N.; Tan, Gang; Wang, Daniel C.

doi:10.1145/1709093.1709094

Cited by 32 publications

(22 citation statements)

References 90 publications

(105 reference statements)

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Appel et al showed how to prove soundness of TALs [5] using (unary) step-indexed models [3,6]. Our logical relation most closely resembles the multi-language relation of Perconti and Ahmed [22] though theirs, without assembly, is simpler.…”

Section: Related Workmentioning

confidence: 85%

FunTAL: reasonably mixing a functional language with assembly

et al. 2017

Self Cite

View full text Add to dashboard Cite

We present FunTAL, the first multi-language system to formalize safe interoperability between a high-level functional language and low-level assembly code while supporting compositional reasoning about the mix. A central challenge in developing such a multi-language is bridging the gap between assembly, which is staged into jumps to continuations, and high-level code, where subterms return a result. We present a compositional stack-based typed assembly language that supports components, comprised of one or more basic blocks, that may be embedded in high-level contexts. We also present a logical relation for FunTAL that supports reasoning about equivalence of high-level components and their assembly replacements, mixed-language programs with callbacks between languages, and assembly components comprised of different numbers of basic blocks.

show abstract

Section: Related Workmentioning

confidence: 85%

FunTAL: reasonably mixing a functional language with assembly

et al. 2017

Self Cite

View full text Add to dashboard Cite

show abstract

“…In comparison with "semantic" approaches (Ahmed, 2004;Birkedal et al, 2010;Ahmed et al, 2010;Birkedal et al, 2011;Schwinghammer et al, 2011), the syntactic approach seems more simple-minded. It is purely about syntax and reduction, whereas the semantic approach involves more complex mathematics.…”

Section: Architecture Of the Proofmentioning

confidence: 99%

“…Here, one can choose to use semantic types (that is, functions of worlds to sets of values), in which case the domain of worlds must be recursively defined; or syntactic types, in which case the interpretation of types must be recursively defined. Either way, subtle recursive definitions are required, and, in order to formulate these definitions in a sound manner, one must usually introduce some form of step-indexing or approximation (Ahmed, 2004;Birkedal et al, 2010;Ahmed et al, 2010). Modeling the higher-order frame and anti-frame rules requires a similar array of techniques (Schwinghammer et al, 2010;Birkedal et al, 2011;Schwinghammer et al, 2011).…”

Section: Architecture Of the Proofmentioning

confidence: 99%

Syntactic soundness proof of a type-and-capability system with hidden state

Pottier¹

2012

J. Funct. Prog.

View full text Add to dashboard Cite

This paper presents a formal definition and machine-checked soundness proof for a very expressive type-and-capability system, that is, a low-level type system that keeps precise track of ownership and side effects.The programming language has first-class functions and references. The type system's features include: universal, existential, and recursive types; subtyping; a distinction between affine and unrestricted data; support for strong updates; support for naming values and heap fragments, via singleton and group regions; a distinction between ordinary values (which exist at runtime) and capabilities (which don't); support for dynamic re-organizations of the ownership hierarchy, by dis-assembling and re-assembling capabilities; support for temporarily or permanently hiding a capability, via frame and anti-frame rules.One contribution of the paper is the definition of the type-and-capability system itself. We present the system as modularly as possible. In particular, at the core of the system, the treatment of affinity, in the style of dual intuitionistic linear logic, is formulated in terms of an arbitrary monotonic separation algebra, a novel axiomatization of resources, ownership, and the manner in which they evolve with time. Only the peripheral layers of the system are aware that we are dealing with a specific monotonic separation algebra, whose resources are references and regions. This semiabstract organization should facilitate further extensions of the system with new forms of resources.The other main contribution is a machine-checked proof of type soundness. The proof is carried out in Wright and Felleisen's syntactic style. This offers evidence that this relatively simple-minded proof technique can scale up to systems of this complexity, and constitutes a viable alternative to more sophisticated semantic proof techniques. We do not claim that the syntactic technique is superior: we simply illustrate how it is used and highlight its strengths and shortcomings.

show abstract

“…But on the other hand, some parts of memory should not be observable. 1 In private regions of memory, compilers should have the freedom to optimize loads and stores of sequential programs: to hoist loads/stores past each other, and past control operations, to eliminate redundant loads and stores, etc.-subject only to dataflow constraints.…”

Section: Observablesmentioning

confidence: 99%

“…We demonstrated that the trusted base could be reduced to less than 3000 lines of source code: about 800 for a proof checker, written in C and capable of checking proofs for any object logic representable in LF; a few lines for the representation of higher-order logic (HOL) in LF; and about 1500 lines to represent instruction encodings and instruction semantics of the Sparc processor [32]. We instrumented Standard ML of New Jersey to produce type annotations at each basic block [13] and we built a semantic soundness proof for the machine-level type system [1]. Other research groups also demonstrated FPCC for other compilers [17,14].…”

Section: Foundational Verificationmentioning

confidence: 99%

Verified Software Toolchain

Appel

2011

Lecture Notes in Computer Science

Self Cite

127

119

View full text Add to dashboard Cite

Abstract. The software toolchain includes static analyzers to check assertions about programs; optimizing compilers to translate programs to machine language; operating systems and libraries to supply context for programs. Our Verified Software Toolchain verifies with machine-checked proofs that the assertions claimed at the top of the toolchain really hold in the machine-language program, running in the operating-system context, on a weakly-consistent-shared-memory machine.Our verification approach is modular, in that proofs about operating systems or concurrency libraries are oblivious of the programming language or machine language, proofs about compilers are oblivious of the program logic used to verify static analyzers, and so on. The approach is scalable, in that each component is verified in the semantic idiom most natural for that component.Finally, the verification is foundational: the trusted base for proofs of observable properties of the machine-language program includes only the operational semantics of the machine language, not the source language, the compiler, the program logic, or any other part of the toolchain-even when these proofs are carried out by source-level static analyzers.In this paper I explain some semantic techniques for building a verified toolchain.Consider a software toolchain comprising, A Static analyzer or program verifier that uses program invariants to check assertions about the behavior of the source program.A compiler that translates the source-language program to a machinelanguage (or other object-language) program.A runtime system (or operating system, or concurrency library) that serves as the runtime context for external function calls of the machinelanguage program.We want to construct a machine-checked proof, from the foundations of logic, that Any claims by the static analyzer about observations of the source-language program will also characterize the observations of the compiled program.We may want to attach several different static analyzers to the same compiler, or choose among several compilers beneath the same analyzer, or substitute one operating system for another. The construction and verification of just one component, such as a compiler or a static analyzer, may be as large as one project team or research group can reasonably accomplish. For both of these reasons, the interfaces between G.

show abstract

Semantic foundations for typed assembly languages

Cited by 32 publications

References 90 publications

FunTAL: reasonably mixing a functional language with assembly

FunTAL: reasonably mixing a functional language with assembly

Syntactic soundness proof of a type-and-capability system with hidden state

Verified Software Toolchain

Contact Info

Product

Resources

About