• Welcome to TechPowerUp Forums, Guest! Please check out our forum guidelines for info related to our community.

Intel Abandons "x86S" Plans to Focus on The Regular x86-64 ISA Advisory Group

AleksandarK

News Editor
Staff member
Joined
Aug 19, 2017
Messages
3,018 (1.07/day)
Intel has announced it will not proceed with X86S, an experimental instruction set architecture that aims to simplify its processor design by removing legacy support for older 32-bit and 16-bit operating modes. The decision comes after gathering feedback from the technology ecosystem on a draft specification that was released for evaluation. The x86, and its 64-bit x86-64 we use today, is a giant cluster of specifications that contains so many instructions rarely anyone can say with precision how many are there. All of this stems from the era of original 8086 processor, which has its own 16-bit instructions. Later on we transitioned to 32, then 64-bit systems with all have brought their own specific instructions. Adding support for processing of vector, matrix, and other data types has increased the ISA specification so much that no one outside a few select engineers at Intel (and AMD) understands in full. From that x86S idea was born to solve the issue of supporting legacy systems and legacy code, and moving on to the x86S ISA, where "S" stands for simplified.

The X86S proposal included several notable modifications, such as eliminating support for rings 1 and 2 in the processor's protection model, removing 16-bit addressing capabilities, and discontinuing legacy interrupt controller support. These changes would have potentially reduced hardware complexity and modernized the platform's architecture. A key feature of the proposed design was a simplified boot process that would have allowed processors to start directly in 64-bit mode, eliminating the current requirement for systems to boot through various legacy modes before reaching 64-bit operation. The architecture also promised improvements in handling modern features like 5-level paging. "Intel will continue to maintain its longstanding commitment to software compatibility," the company stated in the official document on its website, acknowledging that the x86S dream is over.




The company plans to move forward with working closely with industry partners on its x86 Ecosystem Advisory group, which we covered deeply. Today, for Tom's Hardware, Intel spokesperson noted:

We remain deeply committed to the x86 architecture, as demonstrated by the creation of the x86 Ecosystem Advisory Group in collaboration with AMD and other industry leaders. This initiative reinforces our dedication to securing a strong future for x86, building on decades of software compatibility. While we have pivoted away from the x86S initiative, our focus remains on driving innovation and collaboration within the x86 ecosystem.

View at TechPowerUp Main Site | Source
 
That's good news to end the year with!
 
I wonder why they didn't put the x86S plans on the x86-64 ISA Advisory Group table to discuss it as a proposal.

Unless they didn't do anything yet, so nothing to put on the table in the first place.
 
Such a shame to see Intel like this. AMD seems to excel at their Zen architecture and CPU packaging but does not really innovate ground-up new features.
 
Who made that picture? x64 architecture can utilize any memory capacity, beyond 4GB it really has benefits, not just from >8GB.
 
Finally a nice xmas present. Good to hear.

Who made that picture? x64 architecture can utilize any memory capacity, beyond 4GB it really has benefits, not just from >8GB.

double the data seems also wrong in my point of view.
both processors can handle only one instruction. just the registers are more wide. which also has penalties.
other stuff about how the prefetcher, fetcher, execture unit is build is also not considered.
if the processor has logic blocks for certain instructions or not.

that picture just shows how illiterate intel posts pictures. from a processor, graphic card, ethernet, wlan card, storage, sillicion maker I expect much, much, much higher quality. quality in information, information presentation, clarity and compactness of information.
Intel may ask HR to move that person responsible to another department with easier tasks.

--

I read between the lines.

we do not have cash - we stop that product / product line for the future. Let's do it a few days before the holidays so less people will notice it.
 
Last edited:
I don't get what the benefit from dropping 16-bit support would be though. Is there a cost to legacy support? Yes probably but the cost is not that high. Is legacy support the reason why Intel's x86 products are not competitive? I don't think so.

The strongest moat that x86 has is its legendary decades-long compatibility with a massive ecosystem. You can install (with some technical workarounds) very old OSes and software on modern x86 chips. Most other ISAs don't come close, so to unilaterally remove your strongest strength just seemed very foolish and short-sighted to me.

Maybe someone else can educate me on why x86s was a good idea.
 
Why? Couldn’t it potentially have good outcomes in the future?
The legacy bits of x86 are so tiny you would have never noticed the difference. You WOULD notice some legacy applications breaking, however.

It's like touching up the paint on the bottom of your bumper. Yeah, it "improves"it, but nobody would ever notice it.

Besides, there's been repeated evidence that x86 is NOT the problem. Intel lunar lake is pushing out ARM levels of battery life. The problem has been, and always will be, it's core design. Arrow lake proved that too, even with TSMC 3, Intel still slurps amps.

The whole project was a waste of time and money and with Pat gone this seems like a great time to eliminate the project from their books.
 
Such a shame to see Intel like this. AMD seems to excel at their Zen architecture and CPU packaging but does not really innovate ground-up new features.
The one single X86 innovation done in the last 30 years came from AMD (X64) and to this day Intel is licensing it from them (it's a free cross-license technically but yeah).
 
The one single X86 innovation done in the last 30 years came from AMD (X64) and to this day Intel is licensing it from them (it's a free cross-license technically but yeah).
Sse3? Ssse4/4.1/4.2? Avx? Avx 512?

I mean if we're going by your life the last major ARM innovation dates back to the 80s.
 
I think they'll be better served working together with AMD and the x86-64 advisory group in developing a more unified, modern standard that still retains legacy support. Though I do wonder if they might eventually offload some of the more niche ISA to a dedicated co-processor built into the larger chip (or as a chiplet itself). Mainly to run real old 8- and 16-bit legacy ISA while optimizing the main CPU for x86-64. It would require some OS tuning on that side, so the advisory group could talk about that too.
 
Yeah, but, it's not like there would be no options.
Like what, getting a retro PC and deal with all the IRQ and Driver bullshit from back then?

No thanks.
 
I don't get what the benefit from dropping 16-bit support would be though. Is there a cost to legacy support? Yes probably but the cost is not that high. Is legacy support the reason why Intel's x86 products are not competitive? I don't think so.

The strongest moat that x86 has is its legendary decades-long compatibility with a massive ecosystem. You can install (with some technical workarounds) very old OSes and software on modern x86 chips. Most other ISAs don't come close, so to unilaterally remove your strongest strength just seemed very foolish and short-sighted to me.

Maybe someone else can educate me on why x86s was a good idea.
They were trying to change the rules since AMD rocked their keisters
 
They were trying to change the rules since AMD rocked their keisters
I wish they focused on changing their whole management instead (not just the CEO, get rid of the board of directors that keeps hiring substandard CEOs over and over).

It would be more effective.
 

Another thread on x86S that should be linked here IMO.

Anyway, like I said there ... Intel invented a new ISA called APX and proved APX runs on their small ECores.

What use is x86S in the light of APX ? Intel literally made something better so x86S dying off as a project just makes sense.

I don't think it was clear if all the decoding issues / ISA extension issues could be fixed for APX 4 years ago. But today it's (seemingly) implemented on E-cores and efficiently implemented at that.

Intel E-cores are like 144 cores to one die in that new Xeon. Small, efficient enough and massively threaded. It seems like the decoder issue has been solved by the dual-decoder (now triple-decoder in the latest Ultra 7 265k designs).

It always sucks to see projects cancelled. But IMO this one makes strategic sense.
 
I don't get what the benefit from dropping 16-bit support would be though. Is there a cost to legacy support? Yes probably but the cost is not that high. Is legacy support the reason why Intel's x86 products are not competitive? I don't think so.

The strongest moat that x86 has is its legendary decades-long compatibility with a massive ecosystem. You can install (with some technical workarounds) very old OSes and software on modern x86 chips. Most other ISAs don't come close, so to unilaterally remove your strongest strength just seemed very foolish and short-sighted to me.

Maybe someone else can educate me on why x86s was a good idea.
It would simply things. Could also make the CPU's decoder a tad bit smaller, but not by any significant margin. It'd be most relevant to making the boot process way simpler, which would mean your motherboard's firmware would also be simplified.
It wouldn't allow you to install older operating systems anymore, given that this would pretty much kill CSM in favor of an UEFI-only platform, but I wonder how relevant those systems are when it comes to modern hardware.
The legacy bits of x86 are so tiny you would have never noticed the difference. You WOULD notice some legacy applications breaking, however.

It's like touching up the paint on the bottom of your bumper. Yeah, it "improves"it, but nobody would ever notice it.

Besides, there's been repeated evidence that x86 is NOT the problem. Intel lunar lake is pushing out ARM levels of battery life. The problem has been, and always will be, it's core design. Arrow lake proved that too, even with TSMC 3, Intel still slurps amps.

The whole project was a waste of time and money and with Pat gone this seems like a great time to eliminate the project from their books.
From their proposal you wouldn't see applications breaking. Support would still be the same within your operating system (assuming it's running in UEFI).


Another thread on x86S that should be linked here IMO.

Anyway, like I said there ... Intel invented a new ISA called APX and proved APX runs on their small ECores.

What use is x86S in the light of APX ? Intel literally made something better so x86S dying off as a project just makes sense.

I don't think it was clear if all the decoding issues / ISA extension issues could be fixed for APX 4 years ago. But today it's (seemingly) implemented on E-cores and efficiently implemented at that.

Intel E-cores are like 144 cores to one die in that new Xeon. Small, efficient enough and massively threaded. It seems like the decoder issue has been solved by the dual-decoder (now triple-decoder in the latest Ultra 7 265k designs).

It always sucks to see projects cancelled. But IMO this one makes strategic sense.
What you said does make sense, but at the same time those 2 ideas are orthogonal: one simplifies some boot-related logic, while the other actually adds new stuff (like doubling up the visible GP registers).
Both do make sense IMO.
 
Intel leaking money like a sinking ship cuts cost from everything including research. Could be the end of intel if the next CEO is not up to the task
 
@AleksandarK

>>...no one outside a few select engineers at Intel (and AMD) understands in full...

You're Not right.

A lot of software engineers who know how to program using assembler language ( in Microsoft or AT&T styles ) know that stuff.

There are a lot of Software Development Manuals ( SDM ) officially released by Intel and AMD with a lot of another documents, like Erratas. I don't use these documents every day but from time to time I'm forced to look for something I need to learn or understand. I have a set of Intel and AMD SDMs, stored locally on an HDD, going back to 1986:

Intel SD Manuals i386 - Released in 1986
Intel 80386 Programmer Reference Manual.pdf

Intel SD Manuals - Released in 2013
Intel Architectures Optimization Reference Manual.pdf
Intel SDM.Basic Architecture.Vol 1.pdf
Intel SDM.Instruction Set Extensions.pdf
Intel SDM.Instruction Set Reference.Vol 2A 2B 2C.pdf
Intel SDM.System Programming Guide.Vol 3A 3B 3C.pdf

Intel SD Manuals - Released in 2016
Intel Architectures Optimization Reference Manual.pdf
Intel SDM.Basic Architecture.Vol 1.pdf
Intel SDM.Instruction Set Extensions.pdf
Intel SDM.Instruction Set Reference.Vol 2A 2B 2C 2D.pdf
Intel SDM.System Programming Guide.Vol 3A 3B 3C 3D.pdf

Intel SD Manuals - Released in 2017
Intel SDM.Basic Architecture.Vol 1.pdf
Intel SDM.Instruction Set Extensions Programming Reference.pdf
Intel SDM.Instruction Set Reference.Vol 2A 2B 2C 2D.pdf
Intel SDM.System Programming Guide.Vol 3A 3B 3C 3D.pdf

Intel SD Manuals - Released in 2020
Intel SDM.Complete.pdf
Intel SDM.Instruction Set Extensions Programming Reference.pdf

AMD SD Manuals - Released since 2005
AMD64 APM Volume 1.24592.pdf
AMD64 APM Volume 2.24593.pdf
AMD64 APM Volume 3.24594.pdf
AMD64 APM Volume 4.26568.pdf
AMD64 APM Volume 5.26569.pdf
OSRR Family 17h Processors.56255_3_03.pdf
OSRR Family 17h Processors.56255_OSRR-1.pdf
PPR Family 17h Models 00h-0Fh.54945.pdf
RG Family 17h Models 00h-0Fh Processors.55449_1.12.pdf
SOG Family 17h Processors 3.00.55723.pdf
SOG for AMD64 Processors.25112.pdf

AMD Abbreviations
APM - Architecture Programmer's Manual
PPR - Processor Programming Reference
SOG - Software Optimization Guide
OSRR - Open Source Register Reference
RG - Revision Guide

Such a shame to see Intel like this. AMD seems to excel at their Zen architecture and CPU packaging but does not really innovate ground-up new features.

>>...but does not really innovate ground-up new features...

AMD innovated a lot at a micro-architecture level. Also, do Not forget that AMD saved the world from Intel-Itanium-disaster by creating an x86-64 architecture
 
AMD innovated a lot at a micro-architecture level. Also, do Not forget that AMD saved the world from Intel-Itanium-disaster by creating an x86-64 architecture

Saving the world is a giant stretch. The reason Itanium did not achieve any significant market penetration was due to a combination of factors, namely the processors' very high cost, IA-64's binary incompatibility with the established industry standard that was x86 (and woefully slow emulation, to the tune of basically performing between a 486 and P5 Pentium CPU) - notice the media back in 2001 was already calling it the Itanic - once AMD brought 64 bit extensions with most of the 64 bit computing benefits while retaining full x86 compatibility at native performance to the Opteron, Intel followed suit by doing the same thing to Xeon, and ultimately, it was Xeon that killed Itanium. x86 compatibility was simply deemed too important at the time to let go. Nowadays the same scenario would not really repeat itself, if say, an ARM-based monster that performed like a high-end EPYC became widely available, that chip would see significant market adoption simply because software is available for it.
 
Shame, seemed like a good idea to me.

Maintaining backwards compatibility to a 40 year old architecture isn't worth the price. For the few edge cases that require it, emulators (and simulators) exist.
 
Back
Top