Developers of the FEX emulator have published a technical account of one of the hardest problems in running x86 applications on Arm processors: preserving the ordering rules that software expects when the two architectures use substantially different memory models. The issue affects nearly every emulated application because ordinary memory reads and writes sit at the center of program execution.
X86 processors use a model known as Total Store Ordering, or TSO. In simplified terms, it gives programmers comparatively strong guarantees about when writes become visible and how later reads relate to them across processor cores. Arm’s default model is weaker and permits more reordering, giving hardware greater freedom to improve performance and power efficiency. Software compiled for Arm can explicitly request ordering where required, but an emulator must reproduce the assumptions built into code compiled for x86.
FEX’s baseline solution for Armv8.0-A translates x86 loads into Arm load-acquire instructions and x86 stores into store-release instructions. Those operations constrain reordering and produce behavior close to what an x86 program expects. The translation is conservative, however: it can impose stricter ordering than the guest operation actually needs, and applying acquire or release behavior to the enormous volume of memory instructions in a normal program creates overhead.
The project’s benchmarks show why there is no single performance estimate for that cost. Several of the five tested processors slowed significantly when acquire loads replaced ordinary loads. AmpereOne showed particularly weak release-store results in the tested path, while Apple’s M1 also fell below its baseline for some acquire and RCpc load operations. Newer Cortex-X4 and Cortex-X925 designs handled the instructions better, while Qualcomm’s Oryon 3 results suggested different optimization priorities. These are microbenchmark observations from the FEX team, not a general ranking of the processors for all workloads.
Arm has added tools that can reduce the penalty. Since Armv8.3, the architecture requires support for load-acquire RCpc instructions, which offer a form of ordering that can better match some translation needs. But memory ordering and atomicity are separate concepts, and the exact instruction sequence must still preserve the behavior that multithreaded x86 software relies upon. A translation that is fast but occasionally exposes an invalid ordering can produce rare and extremely difficult bugs.
That makes the problem broader than converting one instruction set into another. Dynamic translators also have to account for cache behavior, interactions among cores and differences across individual Arm implementations. An approach that performs well on one chip may be costly on another, even when both comply with the same architectural generation.
The FEX analysis helps explain why x86 emulation quality cannot be judged only by arithmetic or graphics benchmarks. Correctly maintaining shared-memory behavior may consume substantial resources even when the translated application appears to be doing ordinary work. Improvements therefore depend both on smarter translation strategies and on Arm hardware providing ordering operations that are efficient when used far more frequently than native software typically requires.
