A preview of x64 emulation on Windows for ARM

> Home users aren't going to double their budgets to afford an Apple machine...

If I were to switch to a Mac mini I would pay about $350 less than it cost me to build my main workstation/gaming machine. According to the benchmarks and real-world tests, I'd gain quite a bit in performance over my Ryzen build, with a fraction of the power consumption which is currently 120W idle, 310W maxed out as measured by my UPS. Per real world tests, the M1 mini never goes above ~35W and stays cool and quiet even when maxed out on stress tests. Given the fact I no longer play games much at all beyond WoW and a few indie titles, and my non-gaming workflow is 100% doable on macOS, I'm sorely tempted to switch even with my reservations about Apple as a company.

> ...especially one which can't even play most games.

No one buys a Mac for AAA games, that's a fact and probably won't change immediately. With that said, Blizzard has day one native Apple Silicon support for WoW, and the benchmarks indicate the performance (depending on the game engine) sits somewhere between the GeForce 1650 and 1660 for most of the games tested so far. That covers pretty much all non-AAA titles on the performance side, leaving portability as the only real issue. I've seen tests done with Steam games and most macOS native x86_64 games make the transition via Rosetta2 quite nicely.

Not to mention, M1 Macs can now run most iOS apps natively which opens up a horde of games to the platform immediately, including popular titles like Minecraft, Fortnite, and CoD.

Another major difference is the memory model. In X86 other CPU’s must always see the writes of a core exactly in the right order. This limits the ability to reorder store ops significantly. ARM requires a memory barrier for this. This is a major reason why X86 emulation is so slow. One must basically issue a memory barrier after every store op.

M1 actually also implements the X86 memory model too in HW. It’s only usable for the rosetta applications and comes with perhaps 20% perf penalty. But it’s still way better than emulating it with barriers.

In C++ terms it pretty much means X86 is always seq_cst. With ARM one can actually get benefit of the different memory model options. As an example one can do an atomic access without having to flush the whole store buffer out, which is impossible in X86.

Due to the instruction coding and memory model for multicore I don’t really see X86 dominating anymore in the upcoming decades.

And as the modern OoO cores are so similar internally it’s not even a big deal in the end. AMD shouldn’t have any issues with producing a Zen arm core. Switch the inst decoder and that’s pretty much it (ton of design work for sure). Keep the X86 mem model optional for emulation and binary translation can be almost thought as just making X86 instructions into fixed width ahead of time.

>Standardized parts and a well defined firmware interface (and thus "standard" bootloaders instead of a multitude like on ARM)

That was true ~15years ago but less so today. Modern PC EUFI bootloaders are bigger and more bloated than any uboot build in existence, and things like device tree support in linux means that you can support various boards with the same kernel (including boards that don't exist yet). Sure you'll probably still need custom bootloaders for most boards, but it's not like you can swap your motherboard BIOS/UEFI chips and expect them to work either. The PC "platform" with hardcoded physical addresses for your serial ports is nice if you're running DOS but it's not really relevant for modern operating systems which have to employ much more complex hardware discovery mechanisms.

It's true that on ARM it's still a bit anarchic and bespoke in practice but that's mainly because there's no reason to push for strong standardization when every vendor is building their own kernels for their own devices anyway.

But the tools do exist (on Linux at least, not sure about the other OSs), if desktop ARM becomes mainstream things could settle fairly quickly. It's less of a technical problem and more of a "why bother?" problem.

Transmeta was VLIW scheduled at runtime, though, right?

It's a slightly different kettle of fish to do, although the decode itself is presumably the same.

> if desktop ARM becomes mainstream things could settle fairly quickly. It's less of a technical problem and more of a "why bother?" problem.

This is exactly right, but I fear the incentives have changed and we'll never again see something like the x86/IBM-compatible/Wintel world of "standard" inter-compatible systems.

As you say, it's a "why bother?" problem, and no manufacturer will want to bother: Apple has no interest in making it easy to run other OSes, Microsoft wants to sell you "Windows Surface" devices, not general-purpose computers, corporate buyers want a "secure" locked-down environment with a signed bootloader...

Are there any powerful stakeholders who benefit from interoperability?