Arguably, any 32-bit binaries that still need to be supported are old now, and a pure 64-bit environment could afford to run them in emulation/JIT translation/whatever without noticeable performance issues.

They only remove support for 32-bit OSes, not for running 32 bit code in general:

> To further clarify, 32-bit x86 user-space software would continue to work on modern 64-bit operating systems with X86-S.

A lot of Windows binaries, including most Electron apps, are still 32 bit, and are run unmodified on 64 bit Windows.

I'm not much of a processor guy, so besides removing cruft, what does X86S do to set up Intel for competing with the likes of ARM in the future?

Will intel provide software to emulate x86-64 on x86S?

No, because it is still x86-64, it just bypasses the bootstrapping process that exists right now going from 16 bit to 32 bit to 64 bit by starting the CPU in 64 bit mode.

However 32 bit registers and everything will continue to exist, and it will act like todays CPU's that went through the multiple bootstrap rounds to get into 64 bit mode.

Which begs the question as to what 'support' linux needs given that I believe EFI does the job of entering protected mode these days.

EFI only spins up a single core/thread. Starting up the other cores/threads is different than it is now.

To rephrase your question, are there any Long Mode user space changes?

Skimming Intel's spec ( https://cdrdv2.intel.com/v1/dl/getContent/776648 ), the X86S looks really risk-adverse towards changing Long Mode user space.

I don't recognize any changes offhand, but my knowledge of x86 legacy is pretty limited (and will hopefully be obsolete soon).

I wonder if AMD would adopt this too?