The semantics of power and ARM multiprocessor machine code

We present a class of relaxed memory models, defined in Coq, parameterised by the chosen permitted local reorderings of reads and writes, and by the visibility of inter-and intra-processor communications through memory (e.g. store atomicity relaxation). We prove results on the required behaviour and placement of memory fences to restore a given model (such as Sequential Consistency) from a weaker one. Based on this class of models we develop a tool, diy, that systematically and automatically generates and runs litmus tests. These tests can be used to explore the behaviour of processor implementations and the behaviour of models, and hence to compare the two against each other. We detail the results of experiments on Power and a model we base on them.

show abstract

“…The lwz r2,0(r9) at line (6) is in data dependency with the lwzx r4,r10,r8 at line (8), because of the xor r10,r2,r2 between them, at line (7).…”

Section: Resemblance To Sparc Relaxed Memory Order's Preserved Programentioning

confidence: 96%

“…Intra-Instruction Causality An execution witness now includes an additional intrainstruction causality relation iico → , as in [26,8]. For example, executing the load lwz r1, 0(r2)-which semantics is given in Fig.…”

Section: Register Eventsmentioning

confidence: 99%

Fences in weak memory models (extended version)

Alglave

Maranget

Sarkar

et al. 2012

Form Methods Syst Des

Self Cite

View full text Add to dashboard Cite

show abstract

“…Therefore, there exists an invocation or return of a non-flush operation in hs 1 that is mapped to this event by G. Then surjectivity of f 1 implies there exists an invocation or return of a non-flush operation in h which maps to the event in hs 1 . Since this event is of a non-flush operation, there exists an invocation or return in Trans(h) which is mapped to it by g. (iii) f is injective since g, f 1 and G are all injective.…”

Section: Soundnessmentioning

confidence: 99%

“…Whilst these relaxed memory models give greater scope for optimisation, sequential consistency is lost, and because memory accesses may be reordered in various ways it is even harder to reason about correctness. Typical multiprocessors that provide such weaker memory models include the x86 [16], Power [17] and ARM [1] multicore processor architectures.…”

Section: Introductionmentioning

confidence: 99%

Using Coarse-Grained Abstractions to Verify Linearizability on TSO Architectures

Derrick

Smith

Groves

et al. 2014

Hardware and Software: Verification and Testing

View full text Add to dashboard Cite

Abstract. Most approaches to verifying linearizability assume a sequentially consistent memory model, which is not always realised in practice. In this paper we study correctness on a weak memory model: the TSO (Total Store Order) memory model, which is implemented in x86 multicore architectures. Our central result is a proof method that simplifies proofs of linearizability on TSO. This is necessary since the use of local buffers in TSO adds considerably to the verification overhead on top of the already subtle linearizability proofs. The proof method involves constructing a coarse-grained abstraction as an intermediate layer between an abstract description and the concurrent algorithm. This allows the linearizability proof to be split into two smaller components, where the effect of the local buffers in TSO is dealt with at a higher level of abstraction than it would have been otherwise.

show abstract

“…An execution of a concurrent program is sequentially consistent if all reads and writes appear to have occurred in a sequential order that is in agreement with the individual program orders of each thread. In order to improve system performance and allow common hardware optimization techniques such as store buffers, many systems implement weaker memory models such as SPARC's TSO, PSO and RMO [22], Intel's x86 [15], Intel's Itanium [24], ARM and PowerPC [2].…”

Section: Introductionmentioning

confidence: 99%

Generating Litmus Tests for Contrasting Memory Consistency Models

Mador-Haim

Alur

Martin

2010

Computer Aided Verification

View full text Add to dashboard Cite

Abstract. Well-defined memory consistency models are necessary for writing correct parallel software. Developing and understanding formal specifications of hardware memory models is a challenge due to the subtle differences in allowed reorderings and different specification styles. To facilitate exploration of memory model specifications, we have developed a technique for systematically comparing hardware memory models specified using both operational and axiomatic styles. Given two specifications, our approach generates all possible multi-threaded programs up to a specified bound, and for each such program, checks if one of the models can lead to an observable behavior not possible in the other model. When the models differs, the tool finds a minimal "litmus test" program that demonstrates the difference. A number of optimizations reduce the number of programs that need to be examined. Our prototype implementation has successfully compared both axiomatic and operational specifications of six different hardware memory models. We describe two case studies: (1) development of a non-store atomic variant of an existing memory model, which illustrates the use of the tool while developing a new memory model, and (2) identification of a subtle specification mistake in a recently published axiomatic specification of TSO.

show abstract

The semantics of power and ARM multiprocessor machine code

Cited by 72 publications

References 16 publications

Fences in weak memory models (extended version)

Fences in weak memory models (extended version)

Using Coarse-Grained Abstractions to Verify Linearizability on TSO Architectures

Generating Litmus Tests for Contrasting Memory Consistency Models

Contact Info

Product

Resources

About