I came across an article (German, paywall) on the Intel X86-S proposal, which is very interesting. I found the original Intel page around the proposal.
Intel are stating that this is still in the proposal stage and manufacturers and developers should not start making changes to their systems based on it, yet.
In short:
16-bit modes will disappear
32-bit real mode will disappear
32-bit VM86 virtual x86 mode will disappear
32-bit Ring 0 will disappear
32-bit Ring 3 will still be available
32-bit Protected Mode will still be available (my hardware knowledge is not 100%, so not sure if that is the same as Ring 3)
Only 64-bit operating systems will boot on new hardware
On the one side, this is a long awaited chance to get rid of a lot of the legacy cruft clogging up the arteries of the x86 architecture and remove many errors and security weaknesses, on the other side, it means that legacy software will no longer run on new hardware - a perenial problem with newer versions of Windows as well, but now the hardware is, again, taking an active part in killing older software.
Moving forward, it should make the chips more efficient and also more secure, at least a lot of know vulnerabilities will be designed out of the chips from now on.
It should also make operating systems more efficient, as a lot of legacy code required for 16-bit and 32-bit code will be eliminated over night on those new systems. Likewise, the operating systems won’t have to build in workarounds for know architechtural failings in the 16-bit and 32-bit operating modes.
I DMed Steve Gibson on Twitter/X, asking him if he could cover it on Security Now, as I assume this will directly affect SpinRite and the OS he bought a year back, going forward and they will only run on older hardware - given the proposal status and the development pipeline, I assume we have a couple of years until we see it turn up in actual hardware.
A legacy free CPU would work if 32-bit/16-bit legacy OSs are still supported in virtualisation as it seems to be the case. Old OSes like MS-DOS would be out of luck.
I don’t see Intel getting rid of legacy CPUs, but I guess moving forward, they are trying to reduce transistor count dedicated to the legacy architecture so they have space for newer stuff.
The amount of space recovered is actually fairly small. It is the efficiency of the design and validation process that seems to be one of the big drivers - they remove a lot of buggy legacy stuff, that they have to clog up the microcode with workarounds for - as well as increasing security. It will mean reduced costs for Intel in the design and development phase, as well as saving a couple of percent on space.
Old 16-bit OSes won’t work. 32-bit in virtual machines.
ARM has already gone down this route with the ARM v9 cores, which are pure 64-bit, for example, but they are mainly used in devices that don’t have the sort of corporate enforced legacy problems that Intel is stuck with, due to Microsoft.
I heard about this a few months ago and I’m all for it. The simplification of the instruction decoding pipeline and the consumate verification simplifications seems a great benefit.
From an area standpoint, this won’t have much impact, but it should help reduce decode latency some–not as much as it helped ARM as the difference between the older instruction encoding and the new is much larger.
I honestly doubt this, simply because 64bit code is still backwards compatible, especially register naming/access. There is no way to remove this without also completely breaking backward compatibility. A lot of the decode is handling the fact that the instructions have so many variations because of the number and size of registers.
Here’s the “names” (in Assembly) of the registers, depending on size, for example: