x86模拟的噩梦：TSO内存模型
本文深入探讨困扰x86模拟的核心难题：模拟x86总存储排序（Total Store Ordering, TSO）内存模型。这一问题影响每一个模拟应用程序，根源在于ARM定义的弱一致性内存模型与x86严格的TSO模型之间存在本质差异。
内存模型定义了系统中内存访问行为的规则。x86采用最严格的TSO模型，强制强一致性，确保存储操作对所有处理器立即可见；而ARM采用最宽松的弱一致性模型，允许大量硬件优化以提升能效。在ARM上模拟x86 TSO，意味着要克服两者在一致性和原子性上的巨大鸿沟。
从ARMv8.0到LRCPC：性能演进之路
在ARMv8.0-a架构下，模拟器通常将x86内存加载转换为ARM的加载获取（load-acquire）指令，存储转换为存储释放（store-release）指令。这种方案虽然语义正确，但性能代价极高。微基准测试显示，在多款测试CPU中，频繁使用获取/释放指令显著阻碍了性能，因为ARM CPU并非为此类高频率指令设计。
随着ARMv8.3引入LRCPC（Release Consistency Processor Consistent）扩展，情况得到改善。LRCPC加载指令的性能几乎与常规加载持平，解决了大部分内存加载的性能瓶颈。FEX模拟器在检测到该扩展后，会优先使用LRCPC指令替代获取-加载指令。
然而，Apple走出了一条不同的路径。Apple Silicon处理器直接在硬件层面支持x86-TSO内存模型。启用该功能后，常规加载/存储指令即可匹配x86行为，无需额外的LRCPC或屏障指令。这使得M1在模拟x86时实现了近乎原生的性能，尽管在非TSO模式下会有一定的性能损耗，但在模拟场景中收益巨大。
未对齐访问与拆分锁（Split-Locks）困境
x86应用程序常进行未对齐内存访问，甚至跨越缓存行执行原子操作，即“拆分锁”。在x86上，只要操作在缓存行内，硬件保证原子性且不撕裂数据；若跨越缓存行，则触发昂贵的拆分锁机制，但仍保证数据完整。
ARM架构要求自然对齐，未对齐访问会触发对齐故障。FEX通过捕获故障并动态修补代码（插入数据内存屏障DMB）来处理此类情况，但这带来了巨大的性能惩罚。测试显示，Cortex-X4等核心在处理未对齐原子操作时，性能下降约50%；而由于频繁的核态与用户态切换，模拟拆分锁的开销更是惊人。
Qualcomm的Oryon-3核心引入了“相干缓存行”特性，使得位于同一缓存行内的未对齐原子操作性能与对齐操作相当，大幅改善了这一状况。但跨越缓存行的拆分锁仍需模拟，且目前尚无完美的硬件解决方案。Valve通过内核补丁优化了Steam Deck上的未对齐原子处理，显著提升了性能，但这依赖于特定的内核支持。
未缓存内存与PCIe GPU的性能悬崖
在游戏开发中，向GPU传输数据常使用“未缓存”（Write-Combine, WC）内存。在UMA（统一内存架构）系统中，CPU和GPU共享内存，可使用缓存缓冲区避免性能问题。但在配备独立PCIe GPU的平台上，必须使用WC内存。
测试数据显示，ARM平台在WC内存上的存储性能极差，带宽差距高达数百倍。这是因为现有的LRCPC扩展仅优化了加载语义，未解决WC内存的存储一致性问题。FEX目前只能通过禁用TSO模拟来规避，导致PCIe GPU平台的模拟性能远低于UMA平台。未来可能需要新的硬件扩展（如FEAT_LRCPC4）来彻底解决此问题。
展望：硬件协同的未来
从ARMv8.0的艰难起步到如今LRCPC、硬件TSO及相干缓存行的引入，ARM生态系统正逐步完善对x86模拟的支持。尽管拆分锁和WC内存存储等边缘情况仍存挑战，但硬件厂商的持续改进正在缩小差距。随着更多专用指令和特性的落地，ARM平台运行x86游戏的体验有望进一步提升，延续PC游戏生态的生命力。