1. Even x86(_64) can’t run every line of code ever written flawlessly. It can only run the code that is on a compatible architecture, where compatibility largely breaks based on intrinsics used or how old the arch is. You already cannot run everything on a modern x86 processor, only a subset and that’ll get worse when Intel drops support for 16 bit soon.
2. That leaves translation or emulation for the arches that are non-native. Which is exactly what arm does today on all three of the big OSs. macOS, windows and Linux all have translation/emulation layers now so can run most x86 code with varying levels of performance penalty.
3. Many Linux distros support arm. I’m not sure where you’re coming from on this. It’s been multiple decades of support at this point, and even the raspberry pi is a decade old itself now as the poster child for consumer arm64 Linux . They may not support every flavor of it, but that’s also true for x86 systems.
That's a pretty good example actually, the various Pi versions are probably the best supported ARM in existence, and even they are incredibly limited in what they can run.
For some reason the way OS support works on ARM is that every OS needs to explicitly support the exact underlying hardware or it doesn't run. For example the recently released Pi 5 can only really run two OSes right now: Pi OS 12 and Ubuntu 23.10. How is that possible, I ask? Why the fuck isn't the required firmware shipped with the SoC and made compliant to run any aarch64 build of anything? It's not like it's new hardware either, it uses a dated 5 year old Cortex A72.
Meanwhile x64 has apparently done the opposite and standardized hardware to a level where software support is completely irrelevant. Pick any new or old version of Windows or Linux or FreeBSD or whatever, pick any motherboard, CPU, GPU, disk combo and it'll install and just work (with a few exceptions). It baffles me that this standardization that's been a blessing on x64 is impossible to achieve with ARM. I don't need a specific release of Debian with firmware from Gigabyte to work with their motherboard, it doesn't give a shit if it's an Intel or AMD CPU or something third entirely, but for ARM this level of support is apparently like asking for cold fusion.
> that’s also true for x86 systems.
Really? I mean I suppose there must be some very specific OSes out there that aren't compatible, but I've yet to hear of any. Hell, you can even run Android.
That’s largely where the holdup is. Most arm devices use a variety of more unique supplementary hardware that often only distribute their support in binary blobs. So due to lack of ubiquity, the support in distros varies.
If you could skip the rest of the device and focus on the processor itself, the distros would largely all run as long as they didn’t remove support explicitly.
This is the same process as on x86. It’s just that the hardware vendors are also interested in selling the components by themselves, and therefore have a vested interest in adding support to the Linux kernel.
It’s very much the case that when new hardware comes out that you need a new kernel version to support it properly. That is true of processors, GPus and even motherboards. They don’t just magically function, a lot of work goes into submitting the patches into the kernel prior to their availability.
Since arm manufacturers right now have no interest in that market, they don’t do the same legwork. They could. If Intel or AMD entered the fray it would definitely change the makeup.
The one other big issue is there’s no standard BIOS system for arm. But again, it’s just down to the hardware manufacturers having no interest as you’re not going to be switching out cores on their devices.
It is one of those "devil in the details" kinds. In theory, DT would be okay, but it's not. The issue starts with HW vendors failing to create 100% (backwards) compatible hardware. For example, if they need a uart, they fail to hook up the standard baud rate divisor and instead use a clock controller somewhere else in the machine because its already there. So now DT describes this relationship, and someone needs to go hack up the uart driver to understand it needs to twiddle a clock controller rather than use the standard registers. Then, of course, it needs to be powered up/down, but DT doesn't have a standard way to provide an ACPI-like method for that functionality. So now it either ends up describing part of the voltage regulation/distribution network, or it needs a custom mailbox driver to talk to the firmware to power the device on/off. Again, this requires kernel changes. And that is just an example of a uart, it gets worse the more complex the device is.
On x86, step one is hardware compatibility, so nothing usually needs to be changed in the kernel for the machine to understand how to setup an interrupt controller/uart/whatever. The PC also went through the plug and play (PnP) revolution in the 1990's and generally continues to utilize self-describing busses (pci, usb) or at least make things that aren't inherently self-describing look that way. Ex: intel making the memory controller look like a pci root complex integrated endpoint, which is crazy but solves many software detection/configuration issues.
Second, the UEFI specification effectively mandates that all the hardware is released to the OS in a configured/working manner. This avoids problems where Linux needs to install device-specific firmware for things like USB controllers/whatever because there is already working firmware, and unless Linux wants to replace it, all the HW will generally work as is. Arm UEFIs frequently fail at this, particularly uboot ones, which only configure enough hardware to load grub/etc, then the kernel shows up and has to reset/load firmware/etc as though the device were just cold powered on.
Thirdly, ACPI provides a standard power management abstraction that scales from old pentium from the 1990s where it is just traping to SMM, to the latest servers and laptops with dedicated power management microcontrollers, removing all the clock/regulator/phy/GPIO/I2C/SPI/etc logic from the kernel, which are the kinds of things that change not only from SoC to Soc but board to board or board revision to board revision. So, it cuts out loads and loads of cruft that need kernel drivers just to boot. Nothing stops amd/intel from adding drivers for this stuff, but it is simply unnecessary to boot and utilize the platform. While on arm, its pretty much mandated with DT because the firmware->OS layers are all over the place and are different with every single arm machine that isn't a server.
So, the fact that someone can hack a DT and some drivers allows the hardware vendors to shrug and continue as usual. If they were told, "Sorry, your HW isn't Linux compatible," they would quickly clean up their act. And why put in any effort, random people will fund ashai like efforts to reverse engineer it and make it work. Zero effort on apples part, and they get Linux support.
x64 servers and PCs are compatible because all of them adhere to an architectural standard backed by a suite of a suite of compatibility tests defined by Microsoft: https://learn.microsoft.com/en-us/windows-hardware/design/co... and https://learn.microsoft.com/en-us/windows-hardware/test/hlk/ . The ARM world has no similar agreed on standard.
Took them long enough.
Back in the day people liked tech and wanted to use it everywhere and have everything just work every time. Now it seems like everyone just wants to tinker with small projects.
Like, look at all the stuff Bluetooth 5 can do. If that existed in 1997, I think there would be about 5x the excitement. But there are probably more people working on customizing their window manager than doing anything with the big name standards.
Intel only sold CPUs at one point. They needed compatibility with all sorts of hardware. ARM manufacturers, on the other hand, sell SOCs, so they don't want any sort of compatibility.
The only issue I see compatibility-wise is that ARM doesn't have a standard method for an OS kernel to auto-discover peripherals. x86_64 has UEFI and ACPI. ARM manufacturers could adopt that if they wanted to, but apparently they (mostly) don't want to.
Otherwise, non-assembly code written for x86_64 tends to run just fine on ARM, when compiled for it.
Traditionally the Linux-on-ARM market has sucked because every single board computer and phone and tablet has needed its own specially compiled kernel with its own set of kernel patches, and probably its own half-assed Linux distro that never gets any updates.
You can't even buy a USB wifi or bluetooth stick and expect it to work without checking the chipset - let alone use a single distro across the BeagleBone Black, the Xilinx Zinq, the iMX6 and the RPi.
ARM manufacturers don't want compatibility.
Who is they? X86 had IBM to establish a standard. And when IBM wasn't interested anymore, it was Intel who stepped in.