Intel Publishes "X86-S" Specification For 64-bit Only Architecture

[luben]

One question I didn't see raised or answered is if an OS that supports x86s will be able to also run on the current crop of x86_64 processors correctly?

[dragorth]

I don't understand how you can emulate an architecture at boot time for bare metal. Obviously when it comes to VMs, it's a moot issue.

Since there front page states they would utilyze virtualization hardware in the CPU, I would assume it would go something like UEFI boot to their Hypervisor that autodetects the OS boot disk and just runs in a VM.

So, yeah, a VM would be their solution.

It is no different, really, to the MacOS X PPC support through QEMU on current gen PPC64 when they don't support some of the older instructions, they just trap and emulate them with the newer versions or routines that give the expected answer.

I like the hardware better, but there are ways to make the software work.

[arteast]

I've skimmed through the PDF and they've removed everything that wasn't used anyway in modern 64-bit OSes:
- rings 1 and 2, and 32-bit ring 0
- only long paged mode remains, 16-bit and 32-bit PM gone (32-bit userspace still works though)
- CS/DS/ES/SS selectors are basically gone so it's flat address space only; FS/GS base still supported for TLS
- gates and all that privilege-transferring GDT/LDT stuff gone; TSS remains (even though it is almost useless since x64 doesn't support hardware task switching and IOPL/IO bitmap are useless in this ISA - they noted that if someone still needs usermode I/O it can be emulated in-kernel)
- also code/data in GDT/LDT gutted a bit (expand-down and stuff)
That's a _lot_ of cruft they are getting rid of with barely any impact on average user.

So for native 64-bit OS it should be pretty easy to support this ISA: basically if you have UEFI 64-bit bootloader, just don't touch anything legacy you probably don't touch anyway. There are some changes regarding APIC and MP-startup but they are in line with other removals and shouldn't be much of an issue.
For this redux ISA, 64-bit kernel is required, but 32-bit userspace still supported (with some removals that shouldn't affect any "sane" software).
One thing that could mess with existing software: HW virt guests have same restrictions as host, so HW virtualization only covers UEFI boot to 64-bit OS, everything else needs to be emulated.

[edgmnt]

Or if Intel managed to keep "X86-S" capacity to run 32-bit user applications after boot but only killing the 32-bit booting or kernel part, then there may be zero obstacles.

I guess that depends on how much of a burden the 32-bit instruction decoder and MMU parts are. On the other hand, 32-bit pointers are sometimes useful even in non-legacy apps.

[ryao]

That would falsely assume either ARM or RISC-V are objectively better than x86.

x86 is an ISA where you cannot specify different source and destination registers for bit shifts. Using them requires either doing a mov instruction or clobbering the original value. Both ARM and RISC-V support both source and destination registers in their bit shift instructions.

x86 has over 10,000 instructions (or op code/prefix combinations in Intel’s misleading nomenclature) just for SIMD, which waste die area that could be used on better things. Intel originally planned to add even more instructions for 1024-bit SIMD, but their recent troubles with 512-bit SIMD make that seem unlikely. RISC-V on the other hand implemented support for 128-bit, 256-bit, 512-bit, 1024-bit and 2048-bit SIMD with only 171 instructions. ARM did not follow Intel in adding instructions for above 128-bit SIMD until it copied RISC-V to enable it via SVE/SVE2. Best of all is that the RISC-V approach lets you execute 2048-bit SIMD instructions on hardware that only supports smaller SIMD widths by having the hardware implicitly use the smaller width units multiple times. That means that you can often write software only once and have it benefit from newer hardware without having to rewrite/recompile it. This is a substantial time savings for developers and allows users to leverage hardware improvements sooner.

Both ARM and RISC-V are objectively better then x86. In the past, Intel kept x86 on top in the past through a process technology advantage, but that is gone. Now others are able to compete on technical merit, so x86 is naturally losing ground to them, despite x86 having the benefit of inertia. Being forced to compete on merit is why Intel backpedaled on AVX-512 and is looking to throw the other anchors wasting die area overboard, which led to their x86-s plans. That would also be why they have become much more conservative in adding extensions, since they cannot afford the die area cost without a process advantage.

[dragorth]

x86 is an ISA where you cannot specify different source and destination registers for bit shifts. Using them requires either doing a mov instruction or clobbering the original value. Both ARM and RISC-V support both source and destination registers in their bit shift instructions.

x86 has over 10,000 instructions (or op code/prefix combinations in Intel’s misleading nomenclature) just for SIMD, which waste die area that could be used on better things. Intel originally planned to add even more instructions for 1024-bit SIMD, but their recent troubles with 512-bit SIMD make that seem unlikely. RISC-V on the other hand implemented support for 128-bit, 256-bit, 512-bit, 1024-bit and 2048-bit SIMD with only 171 instructions. ARM did not follow Intel in adding instructions for above 128-bit SIMD until it copied RISC-V to enable it via SVE/SVE2. Best of all is that the RISC-V approach lets you execute 2048-bit SIMD instructions on hardware that only supports smaller SIMD widths by having the hardware implicitly use the smaller width units multiple times. That means that you can often write software only once and have it benefit from newer hardware without having to rewrite/recompile it. This is a substantial time savings for developers and allows users to leverage hardware improvements sooner.

Both ARM and RISC-V are objectively better then x86. In the past, Intel kept x86 on top in the past through a process technology advantage, but that is gone. Now others are able to compete on technical merit, so x86 is naturally losing ground to them, despite x86 having the benefit of inertia. Being forced to compete on merit is why Intel backpedaled on AVX-512 and is looking to throw the other anchors wasting die area overboard, which led to their x86-s plans. That would also be why they have become much more conservative in adding extensions, since they cannot afford the die area cost without a process advantage.

Since they are envisioning a cleaner ISA, nothing stops them from using something similar to the RISC-V architecture approach for this new x86s architecture. It wouldn't be the first time they backpedaled on a set of instructions, and you can emulate the extra instructions if the 171 cover most use cases.

That doesn't mean they will do it, however.

[ryao]

And that's why I don't understand the hype around ARM / RISC-V. Maybe those who're hyped about ARM / RISC-V don't give a damn about backwards compatibility, but it's something I deeply care about.

Backward compatibility does not require the hardware to support the same ISA indefinitely. Apple achieved backward compatibility in software through binary translation in Rosetta 2. Microsoft is also doing binary translation to support backward compatibility on Windows. It does not work for kernel mode drivers, but that was not a blocker for the 64-bit transition and it will not be a blocker for the ARM and RISC-V transitions.

Things are even easier in the open source space, where we can just recompile.

A nice feature in RISC-V and ARM are the RISC-V vector extension and ARM’S SVE/SVE2. They let developers write code for higher bit-width SIMD hardware that works on the current bit-width SIMD hardware. When newer hardware comes out, not only does the software still run, but it can take full advantage of increased bit width without rewrites or recompilation. That is not possible with x86.

[darkonix]

Only until x86_128 arrives.

Nah, we should skip it and go directly for x86_256

[mangeek]

The problem with an accessory device is that it won't work for natively booting anything 32-bit, which really is the main appeal of retaining the compatibility. The secondary appeal is anyone who might still be running a Windows version older than 11, where those are highly unlikely to get 32-bit x86 emulation, so, your suggestion would be fine for that. However... OSes older than W11 don't work so well with hybrid CPUs, so... I'm not sure those OSes are going to figure out how to use an accessory CPU.

I think y'all are overthinking this a bit. Nobody is going to need to boot bare-metal legacy operating systems on these, the same way nobody (outside of retro hobbyist hackers) boots bare metal Windows XP or 7 on modern motherboards. If you need bare metal, you buy hardware from someone with long-lived supply chains or the secondary market, and if you need application support you emulate.

I'm quite sure that one of the advantages of this arch is that emulating x86 on it will be easy and efficient compared to emulating on ARM or RISC-V, just like emulating x86 on x86_64, ARM on ARM64, or PPC32 on PPC64 are today. There's no need to have cores or cards to have legacy support, you'll just have something in userland that either emulates or translates. I'm sure some retro hacker type will write a 64-bit x86S bootloader that boots to a fake-but-fast x86 Legacy environment, but it will be a toy, not a tool needing widespread use.

[Min1123]

Reading through the proposal, I think it's an interesting idea. It removes MASSIVE amounts of legacy hardware, and moves support for that into emulation in the virtualization engine. This should lead to a massive decrease in complexity of their frontend ISA to their microps cores. If we aren't moving away from x86 arch in general, this is a nice way for Intel to basically clean up their act.

Still with what's here, it's garbage collection. The proposal specifies removal of basic modes for 16 and 32-bit, removal of some opcodes, and forcing things to use state registers instead of older flags, but I didn't see a single mention of consolidating or making a baseline of SIMD instructions. That means x87, MMX, MMXExt, SSE 1-4xx , AVX 1/2/512, and others all are still there, and all still have/need competing levels/hierarchies of overlapping functionality. I think they should re-baseline the SIMD they have/want to a new superset, and emulate many of the older SIMD instructions by technically running them on the microops for their more advanced SIMD platforms.

I'd also like to see REBAR/LAW/MMR support added/firmly defined to the platform, and maybe fixed instruction length or microop fusion for allowing all ISA-compliant CPUs to support with hardware transparently, or fall back to slower methods while having the capability to still support those instructions.

Also, as a point of contention, that has made it other places in these posts. IA64/Intel64 was the name of Itanium, so, they have mis-referenced their platform throughout the paper. Intel's name for the platform/extension, after they licensed it from AMD, was EM64T (Extended Memory 64-bit Technology) to downplay AMD's involvement in what became the dominant arch.

I still want my POWER back. Libre-SoC news anyone?