[robotnikman]

> x86-64 CPUs keep real mode around so that operating systems can keep booting in the same way ... It’s part of the PC compatibility ecosystem that gives x86 CPUs unmatched compatibility and longevity.

This imo is one of the biggest advantages of x86 currently, at least as a hobbyist. In comparison to ARM based computers (like the raspberry pi for example) where the boot process is different for each device, and usually involves proprietary binaries which the user has no clue of how they work

In comparison, you could re-use, update, and repurpose any old x86 machine to do whatever you need.

[yjftsjthsd-h]

The really annoying thing is that we're so close to doing better - openfirmware is decades old, and if we must throw that away UEFI is in fact portable; we could have UEFI ARM machines with nice normal busses that the OS can enumerate and boot just like x86. But, y'know, that would cost another 10 cents a board so we get to live with the current trash. (I mean, this is even a thing that we do use to boot VMs and Windows on ARM, and AIUI ex. https://libre.computer/ does use UEFI firmware, the adoption is just super limited)

[the_panopticon]

https://www.intel.com/content/www/us/en/developer/articles/t...

[jauntywundrkind]

Opened comments to make sure this was mentioned, X86S (formerly X86-S or X86-Simplified). Getting rid of all the old compat modes & booting straight to 64-bit. See: Intel Continues Prepping The Linux Kernel For X86S, https://www.phoronix.com/news/Linux-6.9-More-X86S . Also mentioned by chipsandcheese: Of course, compatibility can’t be maintained forever. ISAs have to evolve. AMD and Intel probably want to save some money by reducing the validation work needed to support real mode. Intel is already planning to drop real mode.

Personally I think ditching the old real mode systems will be a big boon to hobbyists, not a hindrance (sorry mode 13h users)! Linux/x86 Boot Protocol docs tentatively support this assertion (https://www.kernel.org/doc/html/v6.9-rc1/arch/x86/boot.html). What is helpful is having ACPI and UEFI and other conventions/standards in place.

ARM does have Base Boot Requirements (https://arm-software.github.io/ebbr/), that builds to something vaguely x86 like, but wow there's so many systems that still use hardcoded device trees. I haven't spent that much time, but just a couple hours is all it takes to figure out that uncompressing your dtb, applying an overlay, and recompiling a new dtb is awful & terrible & no way to compute. ARM is used so heavily in consumer devices that it's hard to see what would compel the greater ecosystem to do the right thing, to reform. I also can go read a deck like https://uefi.org/sites/default/files/resources/UEFI%20and%20... (UEFI and ACPI in Arm System Architecture) and appreciate, yeah, well, trying to be compatible & a good citizen is hard; there's specifications on top of specifications on top of specifications (Wei lists 17) to make it happen. x86 has benefited form a history of everyone tending towards intercompatibility, but there's nothing else in computing that's ever had such a strong overriding cooperation motive before.

[tadfisher]

Hardcoded DTBs are still prevalent because ACPI is a fudging mess that has no business being codified further in any standard. Anyone involved should focus their effort on a modern replacement; maybe something WASM-based, because at least that would have a chance of including a well-delimited API and runtime.

[hackeraccount]

That's the best part of x86-64. From a laptop to a large number of enterprise servers (or at least any I use) you're essentially dealing with the same stuff. I think Pi's were the first non x86-64 architecture I'd dealt with to any degree.

OK- there were some SPARC servers but that was a while ago - and they were honestly never any fun.