5 ms·
The scourge of x86 emulation
- dagmx 8d agoFor 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.
- MiroslavPokorny 8d agoWhy doesnt Stream require their binaries to be compiled to some bytecode and transpiled during the install ? THen they wouldnt require any emulator for any new compiles.
- matheusmoreira 8d agoExisting games will not be recompiled for the new bytecode target, and they want all of those games to work regardless.
- MiroslavPokorny 7d agoNo im simply suggesting that Steam take this approach and prepare for the future. One day todays latest x86 will be old and some new architecture will replace it.
- rwmj 8d agoI don't know, but assumed that Valve doesn't require studios to recompile their software or use any special tooling, it's basically just packaging of existing executables. This is also why they do Windows on Linux emulation.
- cassianoleal 8d ago> This is also why they do Windows on Linux emulation. They don't. They use WINE, which as the name says, Is Not an Emulator. :D (I'll let my pedantic self out now)
- mitxela 8d agodespite the funny backronym, Wine actually IS a WINdows Emulator. Someone apparently told them that it's only called an emulator if it's emulating a CPU architecture, but that's not true.
- cdmckay 8d agoI thought it was an implementation of the Win32 API as a compatibility layer. What is it emulating exactly?
- anthk 8d agoDoes Windows NT have a Windows 9x API emulator?
- pjmlp 8d agoWindows NT predates Windows 95 for two years. And yes it did had emulators for Windows 16, and DOS https://en.wikipedia.org/wiki/Virtual_DOS_machine https://en.wikipedia.org/wiki/Virtual_DOS_machine https://en.wikipedia.org/wiki/Windows_on_Windows https://en.wikipedia.org/wiki/Windows_on_Windows
- fredoralive 8d agoIf you squint a bit (well, a lot really), Win32S on 3.1 and Windows 95’s Win32 implementation are Windows NT emulators running on top of 16 bit Windows.
- swiftcoder 8d ago> Why doesnt Stream require their binaries to be compiled to some bytecode and transpiled during the install ? They still have to support the entire back-catalog. It's not reasonable to expect thousands of existing games to port to ARM
- DanielHB 8d agoThis is what Android does with Dalvik/Android Runtime. Apps you download from the store are compiled to bytecode that is then compiled to native code at installation time. With the compilation making use of the native instruction set supported for your device, so it can make use of newer arm instructions on newer devices while still supporting older devices. This is the major reason app installation is so slow in Android compared to iOS (which pre-compiles everything). But it also greatly improves app compatibility with older versions. There is no way Valve would be able to convince all the myriad of game engine developers to support a proprietary (or even open source) bytecode format even in the future. Best they could do is make it an opt-in. Android only pulled it off because Google provides the "engine" (Android SDK) for all apps made for the platform and it did from the start. And even so, most Androids games actually bypass this system entirely and just hand-compile to native binaries anyway. Because, again, the game engines don't want to support this bytecode format and google doesn't offer a C++ toolchain themselves that the engine developers could integrate with.
- cwillu 8d agoSeveral games in their library are actually just game updater/launcher binaries, which manage their associated game assets and binaries externally.
- SSLy 8d agobecause there's no gaming-oriented toolchain for it
- account42 8d agoBecause even with their effective monopoly they don't have the power to bully developers into doing whatever suits Valve. And it would be disastrous for the industry if they did.
- MiroslavPokorny 7d agoNot suggesting they FORCE developers, im simply suggesting that another option for distribution would be an advantage.
- ekianjo 8d agoa dominant position is not a monopoly
- account42 8d agoSure, it just quacks like one.
- raverbashing 8d agoThey do x86 bytecode is bytecode
- DonHopkins 8d agothat bites
- ErroneousBosh 8d agoI mean don't modern CPUs basically just run an x86_64 emulator on a RISC machine anyway? Like there's a layer between the microcode and the actual x86 instructions already.
- raverbashing 8d agoI think it's more like a (kinda) VLIW machine but yes, pretty much
- MiroslavPokorny 7d agoVLIW implies packets of different independent instructions that can be executed in parallel. I dont think this definition is ever true for the vast majority of x86 instructions.
- sph 8d agoYes, but the “architecture-independent” bytecode for these RISC machines that run underneath your various Intel and AMD CPU models is the x86_64 instruction set.
- adwn 8d agoNo, that's a myth. It's true that the instruction decoder in a CPU core translates from ISA opcodes to micro-ops for the backend, but those micro-ops are in many cases functionally very close to the ISA instruction and decidedly not RISC-like. For example, the ADD r/m64, imm32 instruction (read from memory, add constant, write to memory) is translated to a single micro-op on several Zen architectures [1], which is far from anything you could call "RISC". [1] https://uops.info/html-instr/ADD_M64_I32.html https://uops.info/html-instr/ADD_M64_I32.html
- ErroneousBosh 8d agoI hate that you're being downvoted for asking a perfectly reasonable question. Guys, if you don't like the premise of the question, reply and say why, don't downvote. I think it's a good question, and my guess for the answer is this - which is going to be the easier problem to solve? "Hi guys if you want to publish on Steam you have to use this specific tooling and language that'll compile to native code on first run" and everyone just has to do it or "Hi guys we want to be able to publish everything so it runs on Arch Linux that we run on our Steamdeck, even if only Windows binaries are available, so given that Gaben is a billionaire what we'll do is just pay guys to make Wine not suck" You choose.
- 4thguy 8d agoThat will open a can of worms. For one thing, Valve will be accused of trying to create a walled garden. Plus there's the whole problem of supporting the back-catalogue as others have said. --- Maybe the best that they could to is to offer to distribute recompiled versions of the emulated binaries, similar to how they distribute compiled shaders. But I don't know if that would work, especially legally.
- wat10000 8d agoThat dream of write-once-run-anywhere has been attempted for decades and is still a massive struggle. And Steam isn’t in a position to mandate that kind of massive change. They’re big, but they still have competition from other stores and from direct sales.
- MiroslavPokorny 7d agoMost of those write-once-run-anywhere platforms struggle on the UI simply because host o/s are the same but often quite different in L&F. On the CPU level, ignoring native WORA guis, java and dotnet are very successful WORA platforms.
- gwbas1c 8d agoA few reasons: Bytecode can't really abstract the differences in memory model between the two different processors without some kind of consequence. (IE, it would be slower.) I've personally done some high performance multithreaded programming in C# / .Net, but it only "works" because C# / .Net assumes the TSO memory model. (Described in TFA.) In contrast, games need to squeak every cycle of performance out of their chips, and optimizations can be very CPU specific. When games target bytecode, they either won't be able to take full advantage of the hardware, or otherwise will need a lot of platform-specific fallbacks (that negate the point of bytecode anyway.) (This is why I prefer console gaming or "simple" games that don't tax the hardware.)
- MiroslavPokorny 7d agoI appreciate there will parts of a game that have hand rolled assembly, but even those have problems when x86 move forward. In the near future SIMD instructions will double their widths and todays fast code using them will be old. C# solves this problem by providing rich libs, so Microsoft continues to evolve faster functions, without programmers having to the all do the same work again and again.
- well_ackshually 8d agoBecause nobody would publish through them anymore. Because Valve has zero legitimacy to mandate that anyone changes their software for any reason. Because this is such an apple-brained, anti developer, anti user move that noone else in the industry does it. Because Valve mandating that for their own gain would bring in such a gigantic gatekeeper lawsuit. Because you profiled your code, optimized, then you'd then rely on Valve's "transpiler" to not write back absolute dogshit code back to the users. Because if it doesn't work well, people are going to blame the video game developer and never Valve. The list is extremely long, and the only people it would benefit is Valve.
- MiroslavPokorny 7d agoWhat makes you think that i suggested that a neutral bytecode should be the ONLY option ?
- pkasting 8d agoDisclaimer: I work for Valve, but I had nothing to do with Fex or anything related. There are a lot of other replies here, but one additional consideration is which solution is generally beneficial outside the original problem domain. A Steam-specific bytecode is applicable to games on Steam, whereas x86 emulation on ARM is of general interest to many problem domains today. Working on the latter could be viewed altruistically (it benefits the larger community) or self-interestedly (other developers are more likely to do work for us), but either way, it's an argument for the generalist path.
- modeless 8d agoAs 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.
- saagarjha 8d agoWell well well “modeless” has decided to finally see the light of modes
- tancop 8d agoArm was never modeless. Thumb is a separate encoding with different instruction semantics and Jazelle ran Java bytecode. Both of them need a special branch instruction to enter. What they don't have is legacy modes like real, v8086 or native 16/32 protected that have no reason to exist when a CPU in long mode can run 16 and 32 bit code (in compatibility sub mode) just fine.
- sgerenser 8d agoIt was a joke based on the commenter’s username.
- gavinsyancey 8d agoAnd as noted in the article, while that helps a lot with most of the issues, there are some corner-cases they still don't handle.
- MBCook 8d agoYeah, I thought that was interesting. Knowing Apple they must’ve profiled a ton of code and decided the hit from not “fixing“ that wasn’t worth enough. The M chips were already so much faster then the Intel chips Apple was using before (except on Mac Pro maybe) that it was probably still a net win.
- karel-3d 8d ago
- asksomeoneelse 8d agoGreat 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.
- EraYaN 8d agoThe actual product people understood it to be paramount to the success of the product and so I feel like from up high there was actual commitment.
- MBCook 8d agoThey’ve been through this a few times before, and they absolutely know how important it is. If they had tried to move to Apple Silicon and said “but none of your old software will work“ it would’ve been dead in the water. Look at how well the early Windows on ARM efforts went, although they were also hamstrung by hardware.
- pdw 8d agoThe 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-cpus/#320ecacb-31dd-4a74-bd34-de2dbf46b1e0 https://fgiesen.wordpress.com/2026/08/25/memory-ordering-in-...
- Aissen 8d agoA recent study seemed to support Fabian's well written article: https://dl.acm.org/doi/epdf/10.1145/3779212.3790129 https://dl.acm.org/doi/epdf/10.1145/3779212.3790129
- wat10000 8d agoIs this just a question of what one considers to be “significant”? I’d consider 3% to be significant but the authors apparently don’t.
- deater 8d agowell it depends on your error bars. On many modern system you can have +/- 5% variation or more run to run just due to the non-determinism present in modern CPU architectures and operating systems (even things like room temperature, time of day, the number of environment variables, etc, can affect this). While you could maybe run a set of careful experiments to characterize and remove this, in my experience most researchers don't bother. So something as small as 3% would need a lot of convincing to me to make the argument that it is significant.
- wat10000 8d agoMultiple separate questions here. First, is a measured improvement actually real or just an artifact of noise? Second, if it is real, is 3% anywhere close to the true value? Third, if 3% is real, is it an important difference? I'm just commenting on the third one. If 3% is real, it's important. I'm inclined to believe there's a real improvement. They made a lot of different measurements. If the measured improvement was a result of noise, you'd expect a lot of variation an a lot of measurements where TSA was actually faster, and then 3% was the average of that variation. There was a lot of variation (expected, because they were measuring different things) but nearly all of them had TSO being either neutral or slower. Looking at their benchmark graphs, I see two (out of dozens) where TSO was faster. As far as being close to the true value, these results suggest there is no single true value, as it depends on the workload. No surprise there.
- sureglymop 8d agoSlightly 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.
- hodgehog11 8d agoThis honestly sounds like holy grail tech at this point; what kind of battery life are you looking at?
- sureglymop 6d agoI have the Retroid Pocket Nova which has a 5000mAh battery. It applies a CPU underclock by default and also has full support for deep sleep/suspend now. The screen is also Amoled so that helps too. In desktop mode I get about ~7h of continuous light work, e.g. browsing. I often use it plugged into a 21:9 4k monitor though just like a laptop. There I should note that at that resolution it seems limited to 60hz refresh rate. When gaming it changes a bit. But for example, it plays GTA V at least as good as a steam deck but at just ~6W power draw. So much more power efficient. I also sometimes do Switch emulation. But that can be a bit more fiddly as patches are required due to the 4:3 screen ratio. The nicest thing for me though is that it can pretty seamlessly dual boot between linux and android. And even in linux, android apps work super well in waydroid because it's arm based. It feels magical to me... I know this reads like an ad but it truly is holy grail tech to me. Never could've imagined this 5 to 10 years ago.
- ianmarcinkowski 8d agoWild! I don't actually do a lot of gaming, but the idea of having a small android device running desktop linux is what I've wanted for a long time!
- tiahura 8d agoI’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.
- deleted 8d ago[deleted]
- snvzz 8d agoThe sooner RISC-V gets mass adoption and x86 becomes a historical/preservation/retro ISA the better.
- peter_d_sherman 8d ago>"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.
- oofabz 8d agoYou 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.
- mrpippy 7d ago> 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.