Existing games will not be recompiled for the new bytecode target, and they want all of those games to work regardless.

DOS interrupts, for starters.

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

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 doesn't emulated Windows, it is Windows. Wine is not Windows and emulates Windows.

What do you think an emulator is?

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?

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.

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.

Steam has decades of games. It's highly probably a large percentage of them aren't currently even in a buildable state on Intel anymore.

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

Sure, it just quacks like one.

that bites

I think it's more like a (kinda) VLIW machine but yes, pretty much

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

Thanks, I didn't know that and now I do.

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.

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.

That 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.

A 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.)

Because 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.

Disclaimer: 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.

It was a joke based on the commenter’s username.

Yeah, 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.

The word "simply" is doing a lot of work there

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.

It's not the only such CPU, Fujitsu's also have TSO.

They’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.

Multiple 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.

It’s a question of how much resources to allocate to the hardware team, and how much resources to be distributed diffusely to the software engineers but especially to the compiler team.

Even your linked paper contends that the actual observed slowdown is as much as 22% in the Geekbench example, but the thesis is that the slowdown is not inherent to TSO, but merely to the specific hardware implementation. Is it worthwhile for a company to optimize its TSO to chase the final gains, or is it better not to have this feature in the first place and just change the compiler?

Indeed my instinct is that it is better to do this in software, where the programmer clearly communicates which stores are ordered, and which may happen in arbitrary order.

The C/C++ memory model starts with Java's data-race free memory model, but makes data races fully UB. Atomics are introduced into C/C++ that allows fine-grained definition of synchronization, with four different models of atomics: sequentially-consistent (equivalent to Java's volatile), release-acquire, release-consume, and relaxed (which are not synchronizing and are therefore closer to a defined data race than proper atomics). The Java 5 memory model doesn't have the concept of atomics, except that volatile variables act like C/C++ sequentially-consistent atomics.

Relaxed atomics took a couple of tries to specify, and still have a known out-of-thin-air hole that people are still struggling to solve. But the problem with relaxed atomics is that the practical operational semantics are pretty clear, but the formal model is quite tricky for various reasons.

Sequentially-consistent matches the model that most people naively think is going on in hardware (execute a single instruction at a time from a random thread). Release-acquire is a slight relaxation of that model that works well most of the time; the main difference between sequentially-consistent and release-acquire is that release-acquire requires you to specifically release and acquire on the same memory location to get the synchronization, whereas sequentially-consistent synchronizes across different memory locations. Since most multithreaded code tends to have a concept of something like a lock or mutex that is guarding access to a particular region of memory, release-acquire is usually sufficient.

Release-consume is supposed to be release-acquire, but only for data-dependent loads of the consume. This is the only part of the memory model that has really failed, and that's because compilers cannot really guarantee preservation of data dependence in the optimizer. (This also comes up with pointer provenance, FWIW).

As my sibling comment from jcranmer points out, it was only `memory_order_consume` that failed outright. The other aspects of the C++ memory model mostly worked out, at least after revision.

I believe the last attempt to come up with a comprehensive new proposal was P0190 (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p01...), which reduced the ordering-imposing dependencies in the model to essentially just be pointer dependencies (which does eliminate some legitimately useful cases, e.g. stealing bits from pointers). The paper mentions the unresolved problem of control dependencies from compiler knowledge of pointer equality, which is intertwined with the pointer provenance discussions from around the same time.

I would like to see the basic concept realized in another language some day.

I don't think any other architecture ever supported it.

In my opinion, conceptualizing memory consistency in terms of acquire/release is wrong and it confuses many programmers.

One problem is that 2 kinds of ordered loads and stores are not enough, 4 kinds are needed.

Some algorithms need not only load-acquire and store-release, but also a store that is guaranteed to be executed before all subsequent stores and a load that is guaranteed to be executed after all previous loads. These properties are the opposite of those provided by load-acquire and store-release. Except for x86 where any loads and stores behave like this, the other popular ISAs do not have such loads and stores, so stronger than necessary instructions must be used, i.e. load barriers and store barriers. Moreover, the instruction that is named a load barrier in the Arm ISA is not a load barrier, but a stronger barrier, but it must be used instead of a load barrier as no better alternative exists.

Besides the fact that not only load-acquire and store-release, but also other 2 ordered loads and stores are needed, a much more serious problem is that load-acquire is not the instruction that is really needed.

I have never seen any useful algorithm where load-acquire is the correct instruction to use. In all algorithms, what you want is not an instruction, but a loop that compares memory repeatedly, waiting for some condition to be fulfilled. The 4 most frequent kinds of loops that are needed are wait-for-not-equal, wait-for-equal, wait-for-even and wait-for-zero.

These loops may execute a load-acquire, but that is not the desired behavior. What you really need are 2 kinds of barriers, one inside the loop and one immediately after the loop.

The internal barrier must prevent the CPU from speculatively executing many future loop instances beyond the conditional jump that terminates the loop body, as it normally does. On x86-64, the instruction PAUSE provides such a barrier. On Aarch64, I suspect that a load-acquire instruction does inhibit this kind of speculative execution, despite the fact that this behavior is not documented. Otherwise, a CPU executing this kind of loop would waste a lot of energy and resources.

The barrier after such a loop must prevent speculative memory accesses beyond it. The semantics of load-acquire are not really needed, because all such loads are done in a loop and the memory accesses that follow the loop cannot be executed before such a load, due to the control dependency created by the conditional jump that follows the load. Nonetheless, while normal execution is impossible, the CPU can execute speculatively any loads following the loop and only this speculative execution can break the acquire semantics. Therefore what you really need is a speculation barrier after the loop, not an acquire barrier, whose behavior is provided automatically by the loop, even without any instruction with acquire semantics.

On x86-64, if a loop is terminated by an unconditional jump, it is said that such a jump blocks the speculative accesses beyond it. This is why the examples provided by Intel in its optimization manual about how to write this kind of acquire loop show loops terminated with unconditional jumps, even if this makes the loops longer, as otherwise the unconditional jump could have been eliminated by moving the conditional jump at the end of the loop. On x86-64, an alternative to unconditional jumps is the LFENCE instruction, which is a barrier for speculative memory accesses.

The so-called load-acquire instruction of Arm might also implement the textbook behavior of load-acquire, of ordering the memory accesses, despite the fact that this behavior is always superfluous, but it must also have the undocumented behavior of being a speculation barrier for memory accesses, otherwise the Arm CPUs would have been very inefficient. However, dedicated speculation barriers of the 2 kinds needed inside the loop and outside the loop would have been more efficient than a load-acquire instruction.

  > but I've seen some compelling arguments that a relaxed model doesn't necessarily have much of a benefit,

"ELI5" oversimplified explanation why this is insane and can be no other way:

You write A (not in cache), you write B, you write C, ... you write Y, you read Z (in L1d).

In ARM, when A misses L1d, L2, and L3, you can issue writes to B..Y, and the read of Z (which hits in 2 cycles) and go on your merry way, your pipeline sure of the value of Z.

With TSO you CANNOT allow the writes to B..Y to be seen by anyone before A, because everyone expects to only see them after A, so you either buffer them or, eventually, sit on your proverbial ass and wait for A to drain. You might have the buffers to put off the consequences for a while, but that is explicitly a cost ARM lacks, AND(this one hurts the most) you can't simply let the load of Z become an architecturally committed observation before A is done. You can speculate it, but you have to preserve the TSO ordering constraints. Eventually you'll run out of write-buffer slots or other resources, or find that your guess of Z's value was ... wrong. This is an example of how TSO loses perf compared to relaxed. The list of how it gains perf compared to relaxed is shorter: { }

So, in some cases TSO is the same perf as relaxed, in no cases it is faster, in some cases it is slower. So it must be slower overall, since "overall" is a weighted mix of those. "By how much" is a question of detail and workload. However, unless your workload miraculously never suffers a cache miss while a later instruction hits, TSO must be slower. :)

This honestly sounds like holy grail tech at this point; what kind of battery life are you looking at?

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!

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.

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

"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.

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.

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.