Seems like a silly thing to say right when x86 is getting pummelled to death by Apple and Valve, maybe slowly, but steadily, while the rest of the gang also watches on.
This is a funny thing to say when Valve hasn't actually released any ARM device yet, and the Steam Deck is still fully reliant on x86. The ARM hardware they do plan to release relies on x86 emulation, which is something that historically usually doesn't pan out.
The Mac silicon is nice in that it has partial x86 emulation in that it can work in x86 memory store mode.
Since they had control over the hardware, they could punt on one of the hard parts of Rosetta and bake it into Silicon.
Understanding the memory ordering requirements from binary without source and without killing performance by being overly conservative (and hell, the source itself probably has memory ordering bugs if it was only tested on x86) sounds next to impossible.
> Understanding the memory ordering requirements from binary without source and without killing performance by being overly conservative (and hell, the source itself probably has memory ordering bugs if it was only tested on x86) sounds next to impossible.
It is hard, but Microsoft came up with a hack to make it easier. MSVC (since 2019) annotates x86 binaries with metadata describing the codes actual memory ordering requirements, to inform emulators of when they need to be conservative or can safely YOLO ordering. Obviously that was intended to assist Microsoft's Prism emulator, but the open source FEX emulator figured out the encoding (which I believe is undocumented) and implemented the same trick on their end.
Emulators still have to do it the hard way when running older MSVC binaries of course, or ones compiled with Clang or GCC. Most commercial games are built with MSVC at least.
That is actually addressed in the article. Several architectures "pummelled" x86 before. PowerPC, for example. They did not stood the test of time though.
What they did not win was the popularity contest, mostly thanks to Windows - the Wintel market was just too massive to compete with.
But that’s changed somewhat - Apple has managed a larger mind and market share (while switching into ARM). The vast majority of uses are now available on the web, which is CPU agnostic, and there is a huge amount of open source software available.
The only things for which x86 still shines a little brighter are games, and native office. But office is mostly available on web, on Mac, and on Winarm. So games. Which aren’t big enough market mass to sustain the x86’s popularity — and is a segment (soon) under attack by Valve.
> The only things for which x86 still shines a little brighter are games, and native office. But office is mostly available on web, on Mac, and on Winarm. So games. Which aren’t big enough market mass to sustain the x86’s popularity — and is a segment (soon) under attack by Valve.
You've missed a huge segment:
Random in-house apps or niche vertical market apps that are closely tethered with a business workflow to the point that replacing them is a massive undertaking, where the developers at best aren't interested in improving anything and at worst no longer exist.
It absolutely has not. I absolutely agree most of those kinds of apps could, and those that can probably should, but more than enough have not.
I support a lot of dental practices using Patterson Eaglesoft and they still don't officially support VMs in any form, even for the server (despite it working fine) while they have removed all support for using terminal services. Obviously the basic application works fine, but a dental practice needs to be able to take digital x-rays. Shock the sensor drivers only exist for Windows and back when RDP and Citrix were supported it required a special bridge running on both the client (which of course still had to be Windows) and the server.
We used some thin clients back in the day for front desk stations and hygiene rooms that didn't need any special hardware, but the main practice rooms and the pano stations always needed full Windows PCs.
The client app is built with PowerBuilder so it'd require a deep rewrite to support any other platforms.
The server side is a Sybase SQL Anywhere database and a SMB file share so it could easily be run natively on Linux but the vendor can't be bothered.
This is a company that still insists that every user needs local admin privileges, despite literally nothing going wrong when they don't have it, and who usually doesn't support new Windows releases until a few months after it becomes the default for new PCs.
---
There are other dental platforms that do have web interfaces intended mostly to enable the use of iPads and other tablets but switching platforms is far from straightforward for practices with years of data, custom integrations, etc. Even if you are willing to go through the trouble (or starting fresh) those platforms, to my knowledge, still require Windows PCs for digital x-ray support.
I did write “embedded/hardware”. Yes, you need special drivers for your X-ray/drill/whatever so you earned an another decade of windows.
But in the places I frequent (backoffice, municipal, finance) it’s all gone web and rdp-through-web (which is web, in the sense that it doesn’t require windows on the client) with centralized administration with minimal (not quite self-serve but reasonably close) thin client users.
Microsoft keeps trying to go ARM for a decade already, most Windows devs and consumers don't care, backwards compatibility rules on PC world, regardless of Prism and ARM64EC.
Additionally beware what to wish for, as CoPilot+ PC are locked down with Pluton security processor, from XBox and Azure Sphere.
The x86 emulation for fallback is (I’ve heard - not tried) usable for the first time.
Microsoft tried in the past without a Rosetta equivalent; Apple succeeded twice with Rosetta. They did not try to switch cold turkey the way Microsoft did.
Lately I've made making some AWS Lambda functions to do some simple things in Python and chose to use the ARM-based instances because there wasn't any reason not to.
Anecdotally at work (SME) we are pretty much all in on ARM. MacBooks with M-series, AWS Graviton instances, even our CI runners are now ARM to match local development.
I believe it’s more from the point of view of Kernel, Compiler, and Driver developers, not from manufacturers and users. Standards, while not very flexible, are good for building ecosystems.
Nothing yet, but the upcoming Steam Frame VR headset is ARM based. The relevant detail is they're bankrolling the open source FEX x86 emulator, with the goal of bringing the whole Steam back-catalogue to ARM systems.
Now that Google and Apple have to (more-or-less) allow other app stores, I wonder if Valve is bankrolling FEX with the intent of selling games on mobile?
This is a funny thing to say when Valve hasn't actually released any ARM device yet, and the Steam Deck is still fully reliant on x86. The ARM hardware they do plan to release relies on x86 emulation, which is something that historically usually doesn't pan out.