Intel Exploring x86S Architecture, Envisions an Unadulterated 64-bit Future

[lexluthermiester]

x86 is old, and has so much legacy things that it makes it slow and inefficient compared to modern alternatives

That is nonsense. Legacy instructions work fine.

 

[TheLostSwede]

The PSU gets to be more of what it already is, a simple, dumb and reliable brick.

Except ATX 3.0 PSUs with 12VHPWR made sure they're less dumb, at least with regards to power delivery to the graphics card, if the extra four pins are present that can deliver power on demand to the graphics card.

 

[R-T-B]

That is nonsense. Legacy instructions work fine.

No one is saying they don't work, they take up silicon space that could be used for other things though.

 

[Dr. Dro]

No one is saying they don't work, they take up silicon space that could be used for other things though.

This, and from my understanding any features removed are not used or are completely trivial to replace on currently existing 64-bit operating systems with no impact in their existing software catalog's compatibility or performance. Seems like a done deal to me. I'm especially interested in a counter-proposal or agreement by AMD's part.

 

[WhateverAnotherFreakingID]

That is funny because intel only recently stopped production of their IA-64 in 2021.

IA-64 - Wikipedia

en.wikipedia.org

Also:

x86-64 - Wikipedia

en.wikipedia.org

Yeah humans not possessing any form of intellectual collective memory (as opposed to a genetic collective memory carried by the surviving genome) makes our history a dishearteningly sequence of petty revisions punctuating a monstrous blob of plain ineptitude at mutual comprehension.

 

[Wirko]

I found it around:

"So, it was estimated that the Pentium used 30% of its transistors to support the x86 ISA. Since the x86 ISA and support hardware remained relatively constant, by the Pentium 4 era, x86 support was estimated to account for 10% of the transistor count.

Ars Technica' Jon Stokes touches on this x86-RISC decoding cost on The Pentium: An Architectural History of the World's Most Famous Desktop Processor."

TL;DR but I'll read that one, I promise. However, here's my take: the Northwood Pentium 4 had 30 M logic transistors (55 M - 25 M of L2 cache). It was the last purely 32-bit desktop CPU from Intel. A modern CPU can't possibly need more than 30 M per core for 32-bit compatibility, and that's a naïve upper bound, even with new features that came later, such as VT-* and rings.

Now Intel can remove some 32-bit features but they can do something else too: optimise the remaining parts for transistor count, regardless of performance drop. No one would blame them, when was the last time that top 32-bit performance mattered? Right, that was when CPUs were two or three times slower.

So in total, they can save maybe... 10 M transistors per core?

 

[LabRat 891]

My guess is that Intel found security vulnerabilities in 32-bit protected mode and related stuff, or may be expecting to find them in the future, so they will remove functionality that's no longer really needed, just in case.

View attachment 296984
View attachment 296985
View attachment 296986

That makes immense sense.
Since the 20-teens, it seems like there's a new 'vulnerability discovered' every couple years, and some have reached back to the first few generations of X86 chips (and are "unfixable").

 

[nageme]

"So, it was estimated that the Pentium used 30% of its transistors to support the x86 ISA. Since the x86 ISA and support hardware remained relatively constant, by the Pentium 4 era, x86 support was estimated to account for 10% of the transistor count.

Haven't read the article, and I'm not sure what they call "x86 support", but let's use that vague thing for a number. The quoted sentence implies 10% on early-era Pentium 4 (Willamette, 180nm). And on page 2 there it says "Today, x86 support accounts for well under 10% of the transistors on the Pentium 4". The article's from 2004, so let's assume 2004-era Pentium 4 (Prescott, 90nm).

Wikipedia says P4 180nm used 42M transistors, P4 90nm 125M transistors.
42M * 10% = 4M, but let's round up and assume "well under" 10% of 125M is 6M.

I can't find figures for modern Intels, but Zen 4 is 6.5B transistors per CCD (up to two of them) plus 3.4B for the I/O die. In total about 16 billion transistors in the max configuration.

So with a lot of random assumptions:
6M * 16 cores = 96M. 96M / 16B = 0.6%
That's for a current-gen CPU, assuming no multicore/other optimizations, and ignoring cache/logic/whatever density differences.

But it's cleaning house so to speak, this is one of ARM's biggest advantages right now.

Someone should quantify/concretize what that actually means. Cleanup just for the sake of aesthetics isn't useful.
If anything, it seems like modern software development practices are wasting much more potential performance and power than some minimal legacy support hardware. But who knows.

 

[chrcoluk]

So if its just 32bit OS support, makes a lot of sense, I did wonder why 32bit OS's have persisted for so long in distributions.

32bit apps is a different beast, but for now after the further explanation it seems thats not affected.

 

[Deleted member 185088]

I like it, 32bit has become rare to the point that only limited hardware is being used for such systems (embedded CPUs and OSs).

But, they'll have to work with at least AMD, IBM, Microsoft & the Linux community for this to work probably, this is not a simple x86 extension anymore like SSE, AVX, and to be "simple" as they call it, at least Intel and AMD must both agree on basic paths, especially 16bit & 32bit virtualization, it won't be simple anymore if it required separate code paths to address both AMD and Intel systems.

x86 is old, and has so much legacy things that it makes it slow and inefficient compared to modern alternatives (arm, risc-v).

People actually building CPUs disagree with you.

 

[SRB151]

Yeah humans not possessing any form of intellectual collective memory (as opposed to a genetic collective memory carried by the surviving genome) makes our history a dishearteningly sequence of petty revisions punctuating a monstrous blob of plain ineptitude at mutual comprehension.

LOL. Yeah, the Itanic was doing great until 2021. Being made doesn't mean it was useful or profitable. HP had their fingers in co-designing this disaster, and moved a lot of big iron based on it when it first same out. Intel wanted to torpedo this long ago, but HP had too much invested and too many suckers locked into it. Intel nearly succeeded at it until HP won a lawsuit with Oracle to keep the software maintained. Itanic has been a dead chip walking for nearly 10 years. Thanks HP!

 

[lexluthermiester]

they take up silicon space that could be used for other things though.

Not really. The legacy instructions sets in question take up less than 3% of the average Intel CPU P-core and less than 5% of an Ecore(in either case those instructions represent less than 1% of the total die, regardless of model). Keeping them is effortless and doesn't change much. What Intel is pushing for here is to close up "loose ends" in it's ISA, becuase these are all things that can now be done(emulated/simulated) very easily in software. They also fear unknown/undiscovered security vulnerabilities lurking.

So for Xajal to state it's because it's "old" or "inefficient" is just plain wrong and a clear indication of someone who either doesn't understand what's really going on or is just flexing against Intel. Regardless, it's pure moose muffins, putting it bluntly.

For you to say it "takes up silicon space" is less wrong because it is technically correct. However, it's just not anywhere close to the real reason.

I personally have mixed thoughts on this one. On the one hand, who really uses those decades old legacy instructions these days? But at the same time, it's not hurting much for them to be present and on the off chance they become useful again(it's happened), engineering them back in might be a challenge.

 

[R-T-B]

Not really. The legacy instructions sets in question take up less than 3% of the average Intel CPU P-core and less than 5% of an Ecore(in either case those instructions represent less than 1% of the total die, regardless of model).

to be quite frank, I'm more confident that intel has more meaningful data on this than whatever numbers we can guess at.

 

[lexluthermiester]

to be quite frank, I'm more confident that intel has more meaningful data on this than whatever numbers we can guess at.

While true, deducing percentages is not difficult. The instruction sets being removed are from the 386/486/Pentium/Pentium2/Pentium3 era. Those dies were made on lithography scales vastly larger than what today's fabs produce. The transistor counts for those CPU's were numbered in the low millions. Today's CPU's are measured in the 10's of billions and recently crossed 100billion. So using simple math, Intel could easily fit a full 386, a full 486, a full Pentium , a full Pentium 2 AND full Pentium 3 and still come in under 30million transistors, and that includes the original onboard caches. However, Intel is not going to cram a whole set of old cores into modern dies, just the parts that are needed to maintain a compatibility layer. They could throw everything in, but they don't. It gets VERY complicated from there.

So, I was actually being very generous with the percentage estimates above. As I said, Intel is cleaning up it's ISA package and eliminating potential hardware based security risks. Nothing more.

 

[R-T-B]

That actually makes a lot of sense, thanks, never thought about it that way.

 

[Wirko]

While true, deducing percentages is not difficult. The instruction sets being removed are from the 386/486/Pentium/Pentium2/Pentium3 era. Those dies were made on lithography scales vastly larger than what today's fabs produce. The transistor counts for those CPU's were numbered in the low millions. Today's CPU's are measured in the 10's of billions and recent crossed 100billion. So using simple math, Intel could easily fit a full 386, a full 486, a full Pentium , a full Pentium 2 AND full Pentium 3 and still come in under 30million transistors, and that includes the original onboard caches. However, Intel is not going to cram a whole set of old cores into modern dies, just the parts that are needed to maintain a compatibility layer. They could throw everything in, but they don't. It gets VERY complicated from there.

So let's say the 32-bit parts take up 1% or 2% of a P core, or whatever. Even less will be removed because 32-bit code execution ability will remain.

But with the silicon area gained, Intel could cram maybe 0.25 MB of L2 more into each core, or increase some other of the many buffers and small caches that sit in there, with a tangible benefit. Designing CPUs is an iteration with a set of limitations and tradeoffs, you can increase X by a bit but then you can't increase Y, and exactly which workloads will benefit from that? Etc. So even a few tenths of a percent is not negligible, neither in surface area nor in performance.

As I said, Intel is cleaning up it's ISA package and eliminating potential hardware based security risks. Nothing more.

That's a lot even if there's "nothing more". The 32-bit blocks won't develop and maintain themselves, I'd say 1% of Intel engineers' job is associated with them, can we agree on this rough estimate? Intel has some very competent bean counters, they surely do wake up when the corporation's net income goes to (brackets).

Engineers are needed to search for security holes, adapt the blocks to new microarchitectures and new nodes and higher clocks*, simulate, optimise for (at least) area, test, and possibly commit errata that eventually make it to the production silicon. And we're talking about tricky features here, such as protection rings, protected mode or virtualisation support, not just "simple" code execution.

* Unless Intel is cheating, which they should be. As I've said before, no one will miss great 32-bit performance in 2023, so decoders can run at half speed. Slower transistors are often smaller and less hot, too.

 

[lexluthermiester]

So let's say the 32-bit parts take up 1% or 2% of a P core, or whatever. Even less will be removed because 32-bit code execution ability will remain.

I think that is a misunderstanding of how CPUs compute. 32bit code can easily be handled by a 64bit instruction pipeline as long as it's written/compiled properly. For older code and OS can be configured to interpreter older in a way that is compatible with newer instruction sets. The 16bit/32bit pipelines being removed is not trivial, but at the same time when CPU makers removed 8bit instruction sets and some 16bit instructions, 32bit took over seamlessly because the engineering was done properly. 64bit will do the same.

So any 32bit code will continue to run flawlessly.

So even a few tenths of a percent is not negligible

I never said it was. Just stated what I think they're really doing. This is supported by the facts at hand.

As I've said before, no one will miss great 32-bit performance in 2023

Nonsense! There are TONS of things that still run 32bit and NEED to perform well.