An integrated concurrency and core-ISA architectural envelope definition, and test oracle, for IBM POWER multiprocessors

Abstract

Weakly consistent multiprocessors such as ARM and IBM POWER have been with us for decades, but their subtle programmer-visible concurrency behaviour remains challenging, both to implement and to use; the traditional architecture documentation, with its mix of prose and pseudocode, leaves much unclear.In this paper we show how a precise architectural envelope model for such architectures can be defined, taking IBM POWER as our example. Our model specifies, for an arbitrary test program, the set of all its allowable executions, not just those of some particular implementation. The model integrates an operational concurrency model with an ISA model for the fixedpoint non-vector user-mode instruction set (largely automatically derived from the vendor pseudocode, and expressed in a new ISA description language). The key question is the interface between these two: allowing all the required concurrency behaviour, without overcommitting to some particular microarchitectural implementation, requires a novel abstract structure.Our model is expressed in a mathematically rigorous language that can be automatically translated to an executable test-oracle tool; this lets one either interactively explore or exhaustively compute the set of all allowed behaviours of intricate test cases, to provide a reference for hardware and software development.

Simplifying ARM concurrency: multicopy-atomic axiomatic and operational models for ARMv8

“…We express the pseudocode execution semantics in two ways: a definitional interpreter for Sail [Gray et al 2015], with an exhaustive symbolic mode to (re)calculate an instruction's memory and register footprints, and as a shallow embedding, translating Sail into directly executable code, with separate hand-written definitions of the footprint functions. The two are essentially equivalent: the first lets one small-step through the pseudocode interactively, while the second is more efficient and should be more convenient for proof.…”

“…We integrated the Flat operational semantics into an exploration tool rmem, building on the ppcmem tool Gray et al 2015;Flur et al 2016bFlur et al , 2017. It is available at http://www.cl.cam.…”

“…(x86 and MIPS are similarly imprecise, while SPARC and Itanium have precise vendor-defined models.) This prompted extensive work to establish mathematically precise models for ARM and for IBM POWER, initially based on the vendor texts, but later, as the deficiencies of those became apparent, relying more heavily on experimental investigation of the behaviour of processor implementations, and on discussion with ARM and IBM architects of their architectural intent: Flur et al [2017Flur et al [ , 2016b; Gray et al [2015]; Alglave et al [2014]; ; ; ; ; Alglave et al [2010; ; Chong and Ishtiaq [2008]; Adir et al [2003]; Corella et al [1993].…”

“…The operational model builds on Flur et al [2017Flur et al [ , 2016b; Gray et al [2015]; . The MCA architecture could be captured using the Flowing model of Flur et al [2017Flur et al [ , 2016b, as recalled in ğ2, by choosing a flat topology in which all hardware threads are siblings.…”

“…Given that, the model aims to abstract as much as possible from the lower-level microarchitectural detail of actual implementations, while keeping the intended envelope of programmer-visible behaviour: out-of-order and speculative execution are explicit, but in terms of an abstract tree or list of instruction instances, not a concrete pipeline; the instruction semantics are specified in terms of execution of their instruction-description pseudocode from the ARM manual (manually or automatically translated from the ASL used there into the Sail language of Gray et al [2015] and [Flur et al 2016b]), rather than hardware operations; the observable effects of shadow registers and register renaming are included by having instruction instances read from their predecessors rather than having explicit register files and renaming; there are no explicit buffers (of writes, read requests, or barriers); and there is no cache hierarchy or cache protocol.…”