The intro of this article repeats the common assertion that

> ARM is the most relaxed, allowing significant hardware optimizations; and x86 is the most strict, enforcing a very strong coherency model that doesn’t allow a lot of room for optimization

but I've seen some compelling arguments that a relaxed model doesn't necessarily have much of a benefit, https://fgiesen.wordpress.com/2026/08/25/memory-ordering-in-...

For reference , Fex is a translation framework for x86 to ARM much like Apple’s Rosetta2 and Microsoft’s Prism.

Valve sponsor development as it’s also the way the new Steam Frame supports x86 games. It’s also being used (as a fork) in Crossover Beta to replace the use of Rosetta2.

Great article ! This is the kind of content I always hope to find on HN's front page.

I really wonder how things are organized at Apple to allow for vertical integration to work so well. That feature alone must have involved so many people from so many different teams.

> A potential concern is that when jumping between x86 emulation and ARM code, that the ARM code will pay unnecessary overhead due to all its accesses being TSO now. While this is a reasonable concern, the amount of ARM native code executing under emulation approaches 0%.

This may be true when FEX is executing as a usermode whole-process emulator on Linux, but it is not true when FEX is built for Windows(/Wine)'s ARM64EC mode. With ARM64EC a thread could be running a very small amount of emulated code while everything else is native.

I believe Microsoft Office is built as ARM64EC in order to support x86_64 plugins, in this case the entire suite itself (along with all the system DLLs) are native ARM64EC code and the only emulation would be for plugins. Kingdom Come Deliverance 2 has an ARM64EC build where the main game EXE is small and x86_64, but the actual game engine is in an ARM64EC DLL.

I don't know of a good solution for this though, enabling/disabling TSO needs a kernel syscall so is too slow to be doing constantly when entering/leaving emulation. With cases like KCD2 where the game itself is ARM64EC, maybe it could be faster to not use hardware TSO.

As noted in the article, Apple solved this problem six years ago by simply adding an x86-compatible memory ordering mode to their chip when x86 emulation became important. Yet another way Apple's chips lead the industry.

Slightly related but this project (FEX) is amazing. I've been running Armada OS on multiple ARM handhelds and they're viable little linux machines now except with amazing battery life.

Most problems I run into are anti cheat related (EAC, etc.) but those can be circumvented for now. Feels kind of insane how far x86 emulation has come.

You can get around the memory ordering issue if you only emulate a single core. Performance suffers but for many legacy workloads performance is not critical.

>"These two models are basically the two extremes of the spectrum; where ARM is the most relaxed, allowing significant hardware optimizations; and x86 is the most strict, enforcing a very strong coherency model that doesn’t allow a lot of room for optimization. [...] The best way to explain how the differences in memory models work is to start with how x86 handles this. With TSO being very strict in how it operates, the programmer can assume that when a memory store occurs, that this will be coherently visible to all other processors in the system. The weak memory model that ARM has is a bit less intuitive about how it operates. By default the regular memory loads and stores that ARM uses aren’t strictly coherent across processors in your system, allowing the CPU to operate more efficiently most of the time. When a store instruction executes, that piece of memory (the cacheline) isn’t immediately visible to other processors in the system. Saving on precious power and efficiency because it’s expensive in hardware to invalidate other core’s cachelines, or allow them to snoop another processor’s caches."

First of all great article! It's an absolute must-read for anyone who would design a CPU, GPU, NPU, xPU, Compiler, or Operating System.

It's an absolute must-read for any low-level Programmer.

We can almost think of these different ways of doing things (x86 vs. ARM) as a "battle of virtues" -- on the one hand, with x86, the low-level programmer gets guaranteed memory read consistency across all cores when any one core executes any single instruction which writes something to memory.

Virtuous! But, at the expense of constantly running a whole lot of extra circuits per instruction which use power and generate heat. It's necessary, damn necessary, for some instructions though!

But it isn't necessary for all instructions that write to memory, because whether it's necessary or not is determined by a lot of factors -- the program it's in, is the memory address used for shared communication or a shared data dependency between cores, etc., etc.

So, on the flip side, ARM uses what is called a "relaxed" model.

The low-level programmer gives up the x86 memory-consistent-across-all-cores-guarantee for every memory write, and now has the responsibility to issue additional instructions to get other cores to see that updated memory.

On the one hand, you've got more hardware complexity to make software simpler, on the other, you've got more software complexity to make hardware simpler.

Which is the "right" solution? Well I don't know. Both have their plusses and minuses from either side of the equation, hardware designer or low-level software designer. Still, it is a great issue to be aware of, and even though some posters had some good-faith and possibly very valid critiques of the article, I liked it! It's an important issue to be aware of, for hardware and software designers alike.

The sooner RISC-V gets mass adoption and x86 becomes a historical/preservation/retro ISA the better.

I’ve got a port of FEX for MacOS to natively run Wine on M series.

Unfortunately, FEX is anti-AI, so I will have to fork.