The power of processor consistency
SPAA '93 Proceedings of the fifth annual ACM symposium on Parallel algorithms and architectures
The SPARC architecture manual (version 9)
The SPARC architecture manual (version 9)
Memory consistency models for shared-memory multiprocessors
Memory consistency models for shared-memory multiprocessors
Weak ordering—a new definition
ISCA '90 Proceedings of the 17th annual international symposium on Computer Architecture
Towards a Formal Model of Shared Memory Consistency for Intel Itanium(tm)
ICCD '01 Proceedings of the International Conference on Computer Design: VLSI in Computers & Processors
Proceedings of the 18th annual international conference on Supercomputing
Specifying memory consistency of write buffer multiprocessors
ACM Transactions on Computer Systems (TOCS)
What is Itanium Memory Consistency from the Programmer's Point of View?
Electronic Notes in Theoretical Computer Science (ENTCS)
Programmer-centric conditions for itanium memory consistency
ICDCN'06 Proceedings of the 8th international conference on Distributed Computing and Networking
| Hi-index | 0.00 |
Our general goal is to port programs from one multiprocessor architecture to another, while ensuring that each program's semantics remains unchanged. This paper addresses a subset of the problem by determining the relationships between memory consistency models of three Sparc architectures, (TSO, PSO and RMO) and that of the Itanium architecture. First we consider Itanium programs that are constrained to have only one load-type of instruction in {load, load _acquire}, and one store-type of instruction in {store, store_release}. We prove that in three out of four cases, the set of computations of any such program is exactly the set of computations of the "same" program (using only load and store) on one Sparc architecture. In the remaining case the set is nested between two natural sets of Sparc computations.Real Itanium programs, however, use a mixture of load, load acquire, store, store release and memory fence instructions, and real Sparc programs use a variety of barrier instruction as well as load and store instructions. We next show that any mixture of the loadtypes or the store-types (in the case of Itanium) or any barrier instructions (in the case of Sparc) completely destroys the clean and simple similarities between the sets of computations of these systems. Thus (even without considering the additional complications due to register and control dependencies) transforming these more general programs in either direction requires constraining the transformed program substantially more than the original program in order to ensure that no erroneous computations can arise.