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
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.
It's more than thousands, and not only it's not reasonable, it's not possible.
Plenty of games run on some critical optimizations that exploit native code quirks that may or may not hold up only because Windows papers over them by special-casing the game process at OS level. The source of such games may be stuck in IP limbo, with five different studios/companies claiming ownership (three of them dead or bankrupt), and even then, the only person who knows what and how needs to be reimplemented is on a remote tropical island, working for a competitor / happily retired / stuck collecting trash for a living, depending on how their career went.
Takes only a few such cases to turn out to be some well-known games with substantial legacy fanbase hoping to relive some childhood memories, to risk seriously damaging the "supporting everything" marketing angle.
Emulating underlying runtime is safer and more practical choice.
This 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.
> Apps you download from the store are compiled to bytecode that is then compiled to native code at installation time.
This is only true in Android 5 and 6.
Starting with Android 7, due to amount of time it took to compile in tiny ARM CPUs, limited optimisation levels, and Java's dynamic abilities, there was a full reboot of this process.
Which is an Assembly hand written interpreter, intended to allow for quick startup in case the JIT cache is empty, a JIT compiler, and an AOT compiler that only compiles the hot paths that the JIT already had a look into, and during idle times while charging so that it can have the CPU all for itself when doing optimisations.
Additionally several other measures were taken to optmise this process, via Play Store Services, devices can share PGO data gathered by the JIT so that each device doesn't have to start from scratch, thus the interpreter step can be skipped when metadata is available. To further improve this process, developers can do training runs, and ship the metadata themselves on the APKs.
Also during the compilation to native code, depending on code access patterns, the executable code gets remapped so that there is an optimal alignment for the instruction cache when reading from the executable code cache.
Google certainly offers clang as part of the NDK, and game development is one of the few officially supported scenarios to run native code on Android.
Your message seems to be arguing both points at the same time - at least that's how it reads to me; first, that it's absolutely feasible to do this because Android did, and then, that in reality game developers there casually defeated those efforts anyway.
I 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.
despite 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.
If 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.
That 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.
Because 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.
I 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.
Yes, 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.
No, 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".
I 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"
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.
Arm 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.
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.
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.
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-...
A recent study seemed to support Fabian's well written article: https://dl.acm.org/doi/epdf/10.1145/3779212.3790129
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.
Why 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.
> 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
It's more than thousands, and not only it's not reasonable, it's not possible.
Plenty of games run on some critical optimizations that exploit native code quirks that may or may not hold up only because Windows papers over them by special-casing the game process at OS level. The source of such games may be stuck in IP limbo, with five different studios/companies claiming ownership (three of them dead or bankrupt), and even then, the only person who knows what and how needs to be reimplemented is on a remote tropical island, working for a competitor / happily retired / stuck collecting trash for a living, depending on how their career went.
Takes only a few such cases to turn out to be some well-known games with substantial legacy fanbase hoping to relive some childhood memories, to risk seriously damaging the "supporting everything" marketing angle.
Emulating underlying runtime is safer and more practical choice.
This 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.
> Apps you download from the store are compiled to bytecode that is then compiled to native code at installation time.
This is only true in Android 5 and 6.
Starting with Android 7, due to amount of time it took to compile in tiny ARM CPUs, limited optimisation levels, and Java's dynamic abilities, there was a full reboot of this process.
Which is an Assembly hand written interpreter, intended to allow for quick startup in case the JIT cache is empty, a JIT compiler, and an AOT compiler that only compiles the hot paths that the JIT already had a look into, and during idle times while charging so that it can have the CPU all for itself when doing optimisations.
Additionally several other measures were taken to optmise this process, via Play Store Services, devices can share PGO data gathered by the JIT so that each device doesn't have to start from scratch, thus the interpreter step can be skipped when metadata is available. To further improve this process, developers can do training runs, and ship the metadata themselves on the APKs.
Also during the compilation to native code, depending on code access patterns, the executable code gets remapped so that there is an optimal alignment for the instruction cache when reading from the executable code cache.
Google certainly offers clang as part of the NDK, and game development is one of the few officially supported scenarios to run native code on Android.
Games use plenty of native code; so much in fact that when Intel tried to enter the Android tablet market with x86 they had to write an ARM emulator.
I mentioned this in the last paragraph of my previous message...
Your message seems to be arguing both points at the same time - at least that's how it reads to me; first, that it's absolutely feasible to do this because Android did, and then, that in reality game developers there casually defeated those efforts anyway.
Also didn't they actually do this and realize that Windows API on x86/64 was as stable as anything they could invent?
I 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.
> 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)
despite 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.
I thought it was an implementation of the Win32 API as a compatibility layer.
What is it emulating exactly?
Does Windows NT have a Windows 9x API emulator?
If 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.
Windows 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/Windows_on_Windows
Existing games will not be recompiled for the new bytecode target, and they want all of those games to work regardless.
That 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.
Because 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.
Several games in their library are actually just game updater/launcher binaries, which manage their associated game assets and binaries externally.
because there's no gaming-oriented toolchain for it
They do
x86 bytecode is bytecode
I 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.
Yes, 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.
No, 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
I think it's more like a (kinda) VLIW machine but yes, pretty much
that bites
I 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.
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.
Well well well “modeless” has decided to finally see the light of modes
Arm 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.
It was a joke based on the commenter’s username.
A legitimate benefit of vertical integration. They control their own CPUs so they can just do that. Linux has to run on whatever it's given.
And 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.
The word "simply" is doing a lot of work there
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.
Wild! 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!
This honestly sounds like holy grail tech at this point; what kind of battery life are you looking at?
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.
The 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.