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

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.

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

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.

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

No, they don't. x86 is a superscalar processor, and it does what all superscalar processors do--translate the instructions into µops for execution and dispatch to the various execution units, with the µops not being 1-1 with the original instructions. However, it was supposed to be impossible for a CISC architecture to be superscalar, so this is what spawns the myth that it's somehow cheating by executing a RISC architecture under the hood.

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.

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

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

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.

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.

Is this just a question of what one considers to be “significant”? I’d consider 3% to be significant but the authors apparently don’t.

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.

Do you think there would be any worthwhile gains from relaxing address-dependent load ordering, like on Alpha/AXP? Or was that just a lot of extra pain for little reward?

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.