[Krutonium]

It's even worse than that.

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.

[palmotea]

> 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.

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

So you could fit 200,000+ 8086s on that not-so-cutting-edge silicon.

[immibis]

You should use a 16-bit CPU then, or an emulator.

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.

[lysace]

How much overhead (in terms of e.g. transistor count or silicon space) does this add? Surely at most it's a single digit percentage?

[immibis]

There isn't a separate 8086 core in every x64 core. The whole core has "if/then" spaghetti logic scattered throughout to alter its behaviour based on being in 16-bit mode.

At best, they might have been able to confine the needed logic patches to the instruction-decoding front end.

[latentsea]

> So in the first couple sends of power on, your CPU is at various points ARM, i386, x86, and x86_64

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.

[pwg]

Read up on the Intel Management Engine: https://en.wikipedia.org/wiki/Intel_Management_Engine

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.

[ChoGGi]

Cheaper to keep it then to fix all the bugs that may come from removing it?

[immibis]

Because

> it's always possible to just keep building on top of old bad designs, and so much cheaper and faster to do so

[UltraSane]

This is why Intel wants to remove the 16 and 32 bit modes and make 64 bit only CPUs.