Hardware isn't much better actually. There isn't a good way I can show you this, but every x64 CPU contains an entire ARM CPU whose job is to initialize the x64 CPU. And of course it runs two operating systems - TrustZone and Minix.
The ARM Core starts up, does crypto, Loads the SecureOS and the BIOS, then it starts the x86 CPU - In 16 bit mode! Which then boostraps itself through 32 then 64 bit mode.
So in the first couple sends of power on, your CPU is at various points ARM, i386, x86, and x86_64.
Well, what if I want to run a 16-bit OS?
Also, I wonder if the transistor count of a literal entire 8086 processor is so small relative to the total that they just do that.
According to https://en.wikipedia.org/wiki/Transistor_count#Microprocesso...:
1978 Intel 8086: 29,000
2021 Rocket Lake: 6,000,000,000
Compatibility mode doesn't work by having a separate 16-bit core. It's random bits of spaghetti logic to make the core work like a 16-bit core when the 32-bit flag isn't set.
At best, they might have been able to confine the needed logic patches to the instruction-decoding front end.
First I'm learning about this and I'm curious why this needs to be the case? Seems so wild that it works this way, but I'm sure there's a logic to it.
It began life as an "out of band" way to administer servers so that an ops. team could do everything (other than actual hardware changes) remotely that would otherwise need a person to be standing in front of the server in the datacenter poking commands into a keyboard.
It then grew in responsibilities to also support the "secure boot" aspect of system startup, and beyond some Intel CPU version point (I do not remember which point), it exists in every Intel CPU produced.
> it's always possible to just keep building on top of old bad designs, and so much cheaper and faster to do so
What does the ARM CPU do?