Friday, December 20th 2024
Intel Abandons "x86S" Plans to Focus on The Regular x86-64 ISA Advisory Group
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:
Sources:
Intel, Tom's Hardware
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.
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.
52 Comments on Intel Abandons "x86S" Plans to Focus on The Regular x86-64 ISA Advisory Group
Unless they didn't do anything yet, so nothing to put on the table in the first place.
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.
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'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.
I mean if we're going by your life the last major ARM innovation dates back to the 80s.
No thanks.
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.
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.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).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.
>>...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>>...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
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.
They're functionally accelerators for special tasks and basically replace the x87 FPU in a modern-ish (SIMD in x86 has been around since the late 90's, over 25yr now...) sense.
For instance, just to focus on something simple and ignoring the other changes, x86-64 was fundamentally a much bigger change than AVX512 to the x86 ISA just because it added more GPR's.Eeeeh its a lil' stretchy but not by much.
If AMD hadn't been around with a ready competitor ISA, which to read some of the press at the time no one thought would be viable or competitive with Intel's EPIC, and a decently performant CPU to sell so programmers had something to work with immediately then its a given that EPIC would've been pushed massively by Intel everywhere. Including the mainstream desktop.
There would've been no competition without AMD so what would've stopped them?
ARM? They're only started to be competitive in a practical sense within the last few years. MIPS and SPARC were on life support already by the late 90's. Same goes for PA-RISC, POWER/PPC, and Alpha. Everyone more or less was running out of development funds by the mid-ish 90's (choked off by x86 eating their share of the server and workstation market), or being sabotaged by their own management (remember what Carly Fiorina did to HP?) by the time EPIC CPU's began to come to market and had largely given up on competing. At best they were trying to just hold onto some market share but even that was clearly becoming a lost cause by the late 90's for some the smaller players.
Bear in mind too that Intel knew well before launch that EPIC had some rather dramatic performance issues that weren't going to be solved for years at best (remember the "wait for McKinley" sales pitch at launch of Merced in 2001? LOL) and still launched it into the server and HPC markets anyways. And then they kept on trying to push it massively in the server and HPC market too despite knowing it was a stinker. It wasn't until Poulson (in 2012) that they more or less finally threw in the towel and admitted publicly the ISA was a failure and would be cutting it eventually.
That's around 11yr of failure they were willing to try and roll the dice with!!! Intel was extremely serious about trying to push EPIC everywhere at a minimum in the beginning. It was only because there was viable competition in the market that they failed to pull that off.