Modelling the ARMv8 architecture, operationally: concurrency and ISA

Abstract

In this paper we develop semantics for key aspects of the ARMv8 multiprocessor architecture: the concurrency model and much of the 64-bit application-level instruction set (ISA). Our goal is to clarify what the range of architecturally allowable behaviour is, and thereby to support future work on formal verification, analysis, and testing of concurrent ARM software and hardware.Establishing such models with high confidence is intrinsically difficult: it involves capturing the vendor's architectural intent, aspects of which (especially for concurrency) have not previously been precisely defined. We therefore first develop a concurrency model with a microarchitectural flavour, abstracting from many hardware implementation concerns but still close to hardwaredesigner intuition. This means it can be discussed in detail with ARM architects. We then develop a more abstract model, better suited for use as an architectural specification, which we prove sound w.r.t. the first.The instruction semantics involves further difficulties, handling the mass of detail and the subtle intensional information required to interface to the concurrency model. We have a novel ISA description language, with a lightweight dependent type system, letting us do both with a rather direct represention of the ARM reference manual instruction descriptions.We build a tool from the combined semantics that lets one explore, either interactively or exhaustively, the full range of architecturally allowed behaviour, for litmus tests and (small) ELF executables. We prove correctness of some optimisations needed for tool performance.We validate the models by discussion with ARM staff, and by comparison against ARM hardware behaviour, for ISA singleinstruction tests and concurrent litmus tests.

The semantics of transactions and weak memory in x86, Power, ARM, and C++

“…In their seminal paper introducing lock elision, Rajwar and Goodman argued that "correctness is guaranteed without any dependence on memory ordering" [46, §9]. In fact, by drawing on a decade of weak memory formalisations [5,24,45] and by extending state-of-the-art tools [4,40,55], we show it is straightforward to contradict this claim automatically. x ← The crux of our counterexample is that a (non-transactional) CR can start executing after the lock has been observed to be free, but before it has actually been taken.…”

Bridging the gap between programming languages and hardware weak memory models

“…Note that we do not include fri in ppo since it is not preserved in ARMv7 [Alglave et al 2014] (unlike in x86-TSO, POWER, and ARMv8). Thus, as ARMv7 (as well as the Flowing and POP models of ARM in [Flur et al 2016]), IMM allows the weak behavior from [Lahav and Vafeiadis 2016, Âğ6].…”

Promising-ARM/RISC-V: a simpler and faster operational concurrency model

“…It features substantial ISA models for ARM and RISC-V. Moreover it is integrated into the rmem tool [22,23,[39][40][41] that supports exhaustive and interactive exploration, a web user interface, debugging facilities, etc. The biggest example exhaustively checked with Flat so far is a spinlock example from the Linux kernel.…”