[BobbyTables2]

The problem is not the ISA — it’s the whole ecosystem.

How many CPUID flags exist? There are so many interdependencies, it’s even hard to say what even makes sense, without detailed knowledge. SSE without MMX? The reuse of floating point HW for other stuff is also a mess.

A x86 system is a witches’ brew of MSRs, I/O ports, and chipset-specific PCI devices. And that’s just across only Intel CPUs…

How much code has to execute before even a bootloader can run?

Why do we need a damn ACPI interpreter?

Why do we still deal with legacy PCI routing (on all devices) when none actually use it?

The PCI configuration space is a bit of a mess. We should just make a new standard where everything 64bit and memory-mapped only.

Why are we shackled with slow IO port operations that replicate hardware from the era when leaded gasoline was widely available? Some may say this is legacy, yet we still rely on it today!!

Imagine if 1980s systems were shackled with 1940s-1960s compatibility concerns.

We need to start afresh — take all the learnings from the past decades and cast off the legacy crap.

[johnnyjeans]

Most of these gripes exist in all modern ecosystems as a consequence of heterogenous and expansive markets of computer hardware. SoC-land is much, much worse. As an exercise, I'd recommend you try porting 9front to a random unsupported SBC. Personally, after a month of reverse engineering and running into really fun and cool hardware bugs, I gave up.

> Why do we need a damn ACPI interpreter?

Because ACPI is still used and for good reason. The lack of an equivalent in virtually every other ISA ecosystem is enough to laugh them out of the room whenever anyone suggests they're a viable alternative.

No thanks. Keep your ridiculous blackbox that's actively hostile to having new software run on it.

[TheLoafOfBread]

> SoC-land is much, much worse

Exactly. It does not matter what core architecture is being used. What matters is that each system usually has different memory model, which is completely defeating any compatibility

[StressedDev]

We will when you are willing to pay for the massive cost of redoing everything which already works well. Also, are you going to buy everyone new hardware for your new better architecture?

Note that we would probably end up with something which has just as many problems or maybe even worse. Rewrites are very hard and you really need to know what you are doing to get everything right or to even to make things better.

[rbanffy]

> Why are we shackled with slow IO port operations that replicate hardware from the era when leaded gasoline was widely available? Some may say this is legacy, yet we still rely on it today!!

Does any modern x86 wake up knowing it's a modern x86 or do they all still wake up thinking they are 8086's and progressively wake up from a series of nested nightmares until it realizes the truth that it has more registers, 64-bits and SIMD instructions?

Yesterday I was looking at a server board and it had the two-digit POST display. I assume it is updated with those ancient OUT instructions and attached to the last vestiges of an 8-bit ISA PC bus running at 5v TTL levels.

[BobbyTables2]

Today they still boot in 16-bit real mode. Very quickly, it usually switches to 32bit mode for the BIOS, maybe eventually 64bit mode.

Option ROMs still start in real mode (at least for non-UEFI). The system management (SMI) handlers are still launched in real mode but too!

When the OS gets launched, l it brings up the other CPUs in real mode (INIT/SIPI), and has to do all the same gymnastics again…

Even PCI configuration space access is still supported with IO ports and that mode still required for some aspects.

Even today, the serial port still uses IO ports and interrupts just as it did 40+ years ago…

Yep, IO based POST codes are still a thing…