Intel proposes the x86-S architecture for a simpler, more efficient CPU instruction set

Alfonso Maruccia

Posts: 1,013   +301
Staff
Forward-looking: After being beaten by AMD in introducing the first, truly 64-bit instruction set in the x86 CPU world, Intel is now trying to get ahead of its historical competitor by working on a simplified x86 ISA. 16-bit compatibility is gone for good, while 32-bit software should be safe for the time being.

The x86 instruction set was first introduced by Intel in 1978 with the 8086 16-bit CPU, and the Santa Clara corporation is now planning to finally bring its computer processors into the future with a 64-bit mode-only architecture. The proposed x86S (or X86-S) ISA is still in the design and feedback phase, and it would provide one of the largest upgrades to the x86 architecture since the introduction of 64-bit registers and memory addressing with the x86-64 instruction set.

As Intel highlights on its technology blog, the long life of the x86 architecture has resulted in one of the richest software ecosystems existing today with an "enormous" installed base of PC, cloud and mobile devices. The 64-bit architecture known today as x86-64, which was first introduced on the market by AMD and then adopted by Intel 20 years ago, has become the dominant operating mode for modern software and operating systems.

Microsoft doesn't provide a 32-bit only version of Windows 11 anymore, Intel says, and the firmware embedded on Intel motherboards no longer offers native support for "non UEFI64" operating systems like MS-DOS or ancient 32-bit Windows versions. 64-bit operating systems are today's standard for modern computing, as they retain the ability to run 32-bit (Win32) applications almost flawlessly while they have no (native) support for 16-bit applications anymore.

Intel thinks that x86-64 popularity finally provides an opportunity to simplify the x86 hardware and software ecosystem. The new x86-S ISA removes certain legacy modes that have very little utility in modern operating environments, the company says, except for bootstrapping the CPU in 8086 mode and then transitioning to an exclusive 64-bit operating mode.

The x86-S whitepaper provides an extensive list of the changes brought by the new architecture to the classic x86 instruction set. The 64-bit only ISA removes ring 1 and ring 2 from CPU protection hierarchy, as they are now useless for modern software besides ring 0 (kernel) and ring 3 (user applications) modes. 16-bit addressing support is gone too, together with 16-bit real mode, 32-bit applications in ring 0, some "unused operating system mode bits," and more.

X86-S should provide plenty of compatibility for 32-bit Win32 applications, so retro gaming and software zealots like yours truly would be safe for now. As for legacy support of earlier 64-bit operating systems, Intel says that virtualization technology is mature enough to provide software and hardware solutions to keep users happy. Everything else (16-bit, DOS, 32-bit OSes), Intel suggests, will only run in emulators and virtual machines.

Permalink to story.

 
What is the point though, unless CPU's are going to run much faster with less instructions to deal with (especially considering its not like no one uses 32 bit apps at this point)? Or is this Intel trying to make more space to push in their exclusive instruction sets like AVX? Any other company and I would maybe hope its for the greater good, but not with Intel and their historically bad practices...
 
What is the point though, unless CPU's are going to run much faster with less instructions to deal with (especially considering its not like no one uses 32 bit apps at this point)? Or is this Intel trying to make more space to push in their exclusive instruction sets like AVX? Any other company and I would maybe hope its for the greater good, but not with Intel and their historically bad practices...
32-bit apps will still be supported, same as they are now. 32-bit apps on x64 run in 64-bit anyway, just under a special 32-bit submode, which isn't going away. The 32-bit only protected mode will be removed, but modern PCs don't use it anyway, unless for some reason you install a 32-bit OS.
 
Apart from a potential competitive advantage against AMD, which may or may not happen depending on how much Intel and AMD work on this architecture (you never know how these things go with all the patents and cross-licensing agreements), a new architecture could breathe new life into the x64 side of things. Getting rid of legacy stuff allows chip designers and manufacturers to dedicate more silicon to solving modern compute problems, improve power efficiency, and ultimately may allow for a stronger x64 competitor to ARM in the mobile and other spaces.

Intel has seen the writing on the wall for some time now; they know that they need to do more than just catch up in the manufacturing realm. The mobile market remains essentially ARM, and if Intel wants to compete with that, they need an ISA which is leaner, faster, and more modern. ARM is also threatening the desktop and server space, so this isn't just about penetrating the mobile market. Apple silicon (M1, M2, and soon M3) is replacing Intel, AWS Graviton competes effectively with both Intel and AMD processors, and now Microsoft is also working on additional ARM designs (Microsoft needs to up their game on the software side if they want ARM to be a common thing for Windows users, though).

Whether or not the new ISA takes off or even if it works in solving these goals is anybody's guess at this point, but this is potentially a very smart move by Intel, and possibly even more important than catching up to TSMC in manufacturing process.
 
I think they're going in the wrong direction. What the x86-64 architecture needs is for it to be as easy to switch to the mode for 16-bit apps from 64-bit mode as it is from 32-bit mode.
Since that isn't the case, though, dropping what 64-bit Windows can't use is sensible.
Of course, if they did avoid licensing this to AMD, then AMD chips would be the more versatile ones. The result would be it becoming a new Itanium. Also, I am not sure they could, since, after all, they licensed x86-64 from AMD in the first place. If it wasn't for AMD, we would have to switch to Itanium to go to 64 bits, remember?
 
What is the point though, unless CPU's are going to run much faster with less instructions to deal with (especially considering its not like no one uses 32 bit apps at this point)? Or is this Intel trying to make more space to push in their exclusive instruction sets like AVX? Any other company and I would maybe hope its for the greater good, but not with Intel and their historically bad practices...


These step changes to x16, then to x32, then to x64 have proven to be a giant pain in the buttocks for everyone involved in tech. I agree, what exactly is the point of this additional exercise? Where's the real headline benefit for such a huge upheaval of mankind's limited mental resources.

"Simplification" and a gold 'S' badge - is that it??

That's the magical headline sales pitch that's going to get cynics running out the door to give Intel money? Intel should know more than anyone else that computers will never be associated with 'simple' and with quantum around the corner they are only going to get more complicated.

I'm no strategist, but it seems obvious that Intel should better spend it's limited resources piling in on "Quantum for the home & mobile market". Even if quantum proves to be rubbish, a bit like curved TVs, it will at least sell for a few years until Joe Public cotton on.
 
What is the point though, unless CPU's are going to run much faster with less instructions to deal with (especially considering its not like no one uses 32 bit apps at this point)? Or is this Intel trying to make more space to push in their exclusive instruction sets like AVX? Any other company and I would maybe hope its for the greater good, but not with Intel and their historically bad practices...

Aside from the obvious simplification, removing the legacy instructions from the chip allows them to shrink the die which reduces power consumption and heat as well. While your comment indicates that you love to hate Intel, they're the most successful chip maker on the planet and they produce the best performing CPUs at the moment without question.
 
My first thought when I saw the headline was "Why bother, if I lose software compatibility I might as well go to ARM." Which, in fact, I'm sorely tempted to do -- I had an ARM chromebook several years ago which I through Ubuntu on through Chrubuntu and it ran GREAT, and.. unlike Windows... in Linux you have basically all software available natively on ARM (even MIPS, or PowerPC/POWER, or s390 mainframe, almost all the software is available), including an x86/x86-64 emulator for the few apps I would not find a native version for.

But.. this sounds like a sensible plan! Indeed, my older BIOS-based desktop only spends time in 8086 mode long enough to run GRUB, it's in protected mode from then on AFAIK. And my newer systems with EFI, I don't know if they spend ANY time in 8086 mode to be honest. The only likely changes would be to the earliest part of the boot process, in other words (and for EFI, it'd be so early it'd be the BIOS writer's problem, not even the Windows or Linux bootloader having to change anything.)

Regarding ring 1 and 2... the two uses I've heard of them being used are VirtualBox and OS/2. VirtualBox, before VT-X (which VirtualBox has required for several years now...), it would patch the code running in VMs so when the VM would request ring 0, it'd go to ring 1 instead! That way the VirtualBox code (running in-kernel, ring 0) could still intercept and trap things the VM's OS was doing as needed. And OS/2 had the kernel and ONLY the kernel in ring 0, drivers ran in ring 1 or ring 2! VirtualBox actually had a big customer that wanted to be able to virtualize OS/2, so VirtualBox has some support for dealing with OS/2's ring shenanigans and successfully running it in a VM.

No loss there -- I don't plan to use OS/2, and VirtualBox now uses VT-X so it doesn't play with the rings any more either AFAIK.
 
As Moore’s Law continues to slow down, there comes a point where you simply cannot rely on being able to cram more transistors in the same package. Or, put another way, if a newer architecture like ARM or RISC-V requires fewer resources for their ISA than Intel’s and both are built on a comparable process node, then the newer architectures will have the ability to allocate those remaining resources for other optimizations, potentially resulting in higher performance.

Intel used to get away with this because of Moore’s Law and the fact that they had a process node advantage over their competitors.

I wonder how much this is playing into Intel’s thinking with this. Sure sounds like they want to free up some resources for their future designs.
 
Yup. And it's smart, I do all kinds of weird stuff with my systems and I don't think I've used 8086 or virtual 8086 mode for probably 20 years (edit: other than the first second or so of bootup where it starts up in 8086 mode; on EFI, even the Windows or Linux bootloaders are x86 or x86-64 binaries).

You may be wondering (well, you're not probably but...) what if I *do* want to still run some DOS app? Will it work?

dosemu actually uses a "vm86" system call in Linux (put in JUST for dosemu) to enter vm86 mode, for dosemu no. (Additional edit.. 64-bit mode already doesn't support virtual 8086 mode, so dosemu runs a instruction interpreter on 64-bit systems too. I guess the answer is really yes it'll keep working, just don't try to install one of the few remaining 32-bit distros THEN try to run dosemu on there.)

Dosbox, uses an instruction interpreter (either a regular one, or one that recompiles instructions into native ones for speed), it doesn't even care if it's on a x86 system at all let alone one that supports 16-bit instructions, yes it'll keep working.

It turns out VT-X does not support virtual 8086 mode either so VirtualBox and VMware also use dosbox-like techniques for running the early BIOS startup, DOS, etc, so also yes it'll keep working.
 
Last edited:
I can guarantee that the first and most important point for Intel is to annul their cross-license agreement with AMD.

They just dont change...

That doesn't make any sense.

Firstly the cross-license agreement goes both ways where Intel relies upon it to use technology and patents developed & owned by AMD, in fact they are licensing the x86-64 architecture and related patents from AMD who developed it. I also wouldn't be surprised if they are also using this agreement to utilise other AMD patents to develop their ARC GPUs. So unless Intel wants to develop their own architecture that doesn't rely on any of AMD's patents it's in their best interests to keep the agreement that gives them royalty free licensing from AMD.

Secondly the agreement can only be terminated by a single party in the event of a breach of agreement, bankruptcy or change of control of the other company. So even if they wanted to, which they wouldn't, Intel cannot simply annul the agreement just because they want to.

So no it would have absolutely nothing to do with the cross-license agreement. The most important point is to simplify the architecture and the silicon, this reduces manufacturing complexity & costs and can lead to potential optimisations & performance improvements that can be made.
 
That doesn't make any sense.

Firstly the cross-license agreement goes both ways
...
Secondly the agreement can only be terminated by a single party in the event of a breach of agreement, bankruptcy or change of control of the other company.
Thirdly, given that they are only removing instructions and (possibly) a few registers, I can't see a scenario where this would affect any existing agreements. Even if some other company besides AMD only had a license to current Intel tech and no future tech, it seems like it'd be legally difficult for Intel to litigate against some company for REMOVING instructions from their new lines of CPUs.
 
Back