To add to this: The POWER7 through POWER9 processors from IBM implement an equivalent to this called "SAO", or "Strong Access Ordering Mode". To quote an IBM e

To add to this: The POWER7 through POWER9 processors from IBM implement an equivalent to this called "SAO", or "Strong Access Ordering Mode". To quote an IBM engineer: > Currently, power has a weaker memory model than x86. Implementing a stronger memory model allows an emulator to more efficiently translate x86 code into power code, resulting in faster code execution. What's interesting is IBM publishes pretty detailed manuals about their processors. You can take a look at the POWER9 CPU manual [0] and search for "SAO". You'll see just how deep down support for this mode goes. To implement this sort of strong memory ordering requires modifications e.g. SAO mode introduces a new pipeline hazard to the L2 cache and requires deep support in the MMU, including corner cases like the virtual memory for VMs and nested VMs. It's not a casual addition to the uarch. EDIT: It just occurred to me Apple has taken a very different approach to solving this problem. From what I can tell, TSO on apple's CPUs is just process state implemented in their "high performance" cores that you get from flipping a bit in the MSR register (?). IBM's version is implemented in the memory system, and is applied to pages of memory (on Linux you call mprotect to mark a page SAO). TSO-semantics are then applied regardless of which core on a potentially multiprocessor, SMP system accesses it. The Apple implementation seems to be more limited -- but in a totally inconsequential way (can't share data between TSO and non-TSO processes). But it does beg the question, what happens when you have shared memory between a Rosetta 2 process and native ARM code? If the ARM code is running on a core without TSO, what gremlins come out to eat your data? [0] https://www.setphaserstostun.org/power9/POWER9_um_OpenPOWER_v20GA_09APR2018_pub.pdf https://www.setphaserstostun.org/power9/POWER9_um_OpenPOWER_...