It's been a long time since Intel or AMD made any "x86" CPUs...😉 A few years ago Intel even announced it was no longer making x86 CPUs, and of course that was met with jeers by the unwashed masses, especially Mac aficionados, who still think Intel and AMD CPUs are built like 2/3/4/86's (Mac-centric publications are generally about 20 years behind the curve when talking about x86--or were last I looked.) Current CPUs are backwards compatible with the old x86 ASIC, to an extent, but that is just a relatively tiny part of their circuitry today. The main features of today's x86 CPUs are not found in the actual x86 ASIC CPUs of yore...😉 We have RISC/CISC hybrid designs now and for the last several years. Likely, this Intel project died due to simple obsolescence, as Intel is still cutting out the dead wood internally.
P.Amini
Reputable
- Jan 20, 2021
- 97
- 70
- 4,610
Lol, ok Intel or Amd employee. Maybe in 1999 you would have been right (with a nice prediction about social medias).
But today x86 is the standard that prevents innovation because it’s obsolete (CISC had proven to be the wrong way) and locked between only two companies. It forces pro/consumers to give their money to either A or B, when we could have the entire alphabet of choice.
- Jan 20, 2010
- 17,561
- 8,861
- 79,540
Yeah, and the ARM v. Qualcomm lawsuit just shows that custodianship of a CPU ISA really can't be entrusted to a single company. At least, not if that company is allowed to design products that compete with some of it architecture licensees.
I don't think RISC-V is a technically superior solution, but it's certainly a more market-friendly one. Bring it on!
- Dec 22, 2024
- 5
- 1
- 15
Have you ever programmed in Assembler i x86 instructionset?
No, it's time to move on to a modern ARM.
Yes!!! Ahah
People who are defending atrocious x86 do not know how rotten the assembly is under the hood (they don’t know what assembly is too.. but they talk loud as always)
Those who know how x86 assembly vs arm/risc-v assembly can’t wait that x86 disappears.
Risc-v assembly is just an elegant masterpiece compared to x86.
Like a vector shape compared to a maze drawn by a 5yo…
- Jan 20, 2010
- 17,561
- 8,861
- 79,540
I feel bad for the engineers who have to actually implement it, and then make sure that every little dark corner of the ISA works exactly like it's supposed to.
Oh, and you have to somehow decode multiple instructions in parallel it, so that it's fast. What makes that even harder is not knowing where one instruction starts until you at least figure out the previous instruction's size! I'm pretty sure they play some tricks with the I-cache, so that it does the first step of decoding to make it easier for the actual decoder block to find those instruction boundaries.
- Dec 22, 2024
- 5
- 1
- 15
Just a sidenote.
In the mid 90'ties AMD and Intel shifted to RISC processors with microcode (Microcode invented by IBM in the 60'ties).
So the x86 CPU's we have today, is actual "software emulation" of x86 instructionset in "old assemblercode" on a "hardware" RISC processor.
So just think if they with little change, it then will be on the ARM processor standard.
In the mid 90'ties AMD and Intel shifted to RISC processors with microcode (Microcode invented by IBM in the 60'ties).
So the x86 CPU's we have today, is actual "software emulation" of x86 instructionset in "old assemblercode" on a "hardware" RISC processor.
So just think if they with little change, it then will be on the ARM processor standard.
JeffreyP55
Distinguished
- Mar 3, 2015
- 725
- 180
- 19,070
Thirty 30+ years ago I was the quintessentially Intel fanboy. AMD finally started showing sighs of life and broke the G1ig CPU non-barrier. When I started overclocking it was by bumping up the crystal oscillator. AIO? Open ended.... German submersible fish tank pump, reservoir on top of the case, plus huge tubing. . The machined CPU and GPU copper blocks where works of art.
Long story longer?
Started building AMD PC's for people about 1997 or so, but never myself. 2025? Until Intel (if they ever do) wakes up from their self induced coma...... For now, AMD 100%..
Can Intel find their way home?
- Jan 20, 2010
- 17,561
- 8,861
- 79,540
Microcode was always a thing in x86 processors. It's just the flavor of microcode that changed. As they moved to a pipelined architecture, it favored a more RISC-like style of micro-ops, rather than the horizontal microcode used in older CPUs.
It's not emulation, because the CPUs have all the hardware resources and semantics that align with the x86 ISA. When you emulate an ISA, a lot of effort (and some loss of efficiency) goes into papering over those differences.
Well, this was basically how Jim Keller described AMD's rationale for launching the now-cancelled K12 project. However, as I mentioned above, it's not as simple as bolting on a different frontend. There are backend changes needed for true binary compatibility.
Microsoft and Apple have both grappled with some of the subtle semantic differences between ARM and x86, with their emulation layers. Apple introduced a special operational mode of their M-series CPU cores, which adjusts the function of the hardware to match the way x86 handles certain things. If you try to emulate without such hardware support, you suffer additional efficiency loss.
- Dec 22, 2024
- 5
- 1
- 15
Yes, that's the point,
The RISC model is such much faster than the x86 standard,
which is based on CISC model, and is much smaller in size in CPU.
(but some of the simple x86 instructions they have made in hardware)
When you are using microcode then the ISA is't the same at hardwarelevel,
as you are showing external to software.
From "x86 Wiki":
"it used a strategy such that dedicated pipeline stages decode x86 instructions into uniform and easily handled micro-operations, a method that has remained the basis for most x86 designs to this day"
- Jan 20, 2010
- 17,561
- 8,861
- 79,540
RISC-like micro ops are easier to pipeline and reschedule than horizontal microcode. That's why they did it.
If you were building an ultra low-power x86 core, like something operating at the level of micro-Watts, you might find it still it more efficient to stick with horizontal microcode.
The definition of ISA (Instruction Set Architecture) is what software sees. Along with the System Architecture, it defines the hardware/software interface.
Most recent ARM cores also have an internal translation layer to m-ops. In fact, all modern, superscalar cores probably have a decode stage, no matter RISC or not. The only exception to this might be VLIW, since their physical and architectural registers are the same.
I'd also point out that none of this has anything to do with x86s.
Last edited:
- Dec 22, 2024
- 5
- 1
- 15
Yes, The starting point was the x86S was a cleaner x86 instructionset (Intel say a new x86 standard), to keep the x86 alive.
But why using such much affort finetuning the chipdesign to go faster and faster, and not just go with a RISC CPU or the ARM CPU.
- Jan 20, 2010
- 17,561
- 8,861
- 79,540
It's getting rid of some legacy, but nothing that affects normal 32/64-bit apps or modern operating systems. That's why Intel thought it would be easy to push through - because it's mostly just getting rid of stuff that has fallen out of current usage for a while. It doesn't make x86 any less CISC-like or more RISC-like.
Indeed, some are doing just that. ARM and RISC-V, mostly. China has Loongson, which is loosely based on the MIPS ISA (traditionally regarded as RISC).
Last edited:
JeffreyP55
Distinguished
- Mar 3, 2015
- 725
- 180
- 19,070
Windows '95 killed my beloved full DOS command support. Bring it back! Just a random thought... J/K
Does it even make sense using the RISC/CISC terms these days, for the mainstream processors?
Even the more "RISC-y" CPUs include SIMD extensions, AES acceleration and whatnot. They don't necessarily have 1-cycle-per-instruction timings... so what's left that's traditionally associated with RISC - exclusively load/store, fixed-length instructions? I'm not sure if e.g. ARM's LDM/STM instructions fit a dogmatic load/store world-view?
And sure, x86 has decades of bloat, but how much does *that* matter, really? If we ignore aesthetics and look purely at stuff like transistors used or performance hit for leaving the old stuff in?
Even the more "RISC-y" CPUs include SIMD extensions, AES acceleration and whatnot. They don't necessarily have 1-cycle-per-instruction timings... so what's left that's traditionally associated with RISC - exclusively load/store, fixed-length instructions? I'm not sure if e.g. ARM's LDM/STM instructions fit a dogmatic load/store world-view?
And sure, x86 has decades of bloat, but how much does *that* matter, really? If we ignore aesthetics and look purely at stuff like transistors used or performance hit for leaving the old stuff in?
- Jan 20, 2010
- 17,561
- 8,861
- 79,540
IMO, there are several key features of an ISA that make it RISCy:
- dedicated load/store instructions
- register-only operands
- fixed-size instruction words
Those set apart x86 from pretty much the rest of the modern ISAs out there. I know one ISA supports a mix of 32-bit and 64-bit instruction words, but I forget which (RISC-V?). I think that's still not nearly as bad as the variable-length situation we have with x86.
As for LDM/STM, those didn't get carried forward to AArch64. ARM replaced them with the LTP/STP instructions, which only operate on up to 2 registers.
Speaking of loads and stores, x86 also has the strongest memory ordering guarantees of the ISAs currently in common use. This can incur additional overhead. Interestingly, Apple's M-series CPUs have a special TSO mode they use for x86 emulation, so someone decided to enable it on AArch64 code and see just how much performance impact it had.
In the most extreme result of the benchmark suite they ran, weak ordering provided a 24.3% speedup over total store ordering! Overall, the benefit was just shy of 9%.
It matters when trying to make wider decoders. Decoder width becomes crucial, when you start executing outside of the uop cache, such as in highly-branchy code. AMD has never gone above a 4-wide decoder. In Zen 5, what they did was to add a second decoder, but these decoders are tied to SMT threads. Intel has gone up to 6-wide, in its P-cores, but this pales in comparison to the 10-wide decoders in ARM's biggest cores and I don't even know what Apple is now up to.
Also, by restricting their new cores to 64-bit only, decoding is now so cheap that ARM found it can completely get rid of its mop caches, which provides additional transistor and power savings.
As for just "leaving the bloat in", I think maybe the legacy Intel wanted to drop could provide some simplifications in key critical paths. Not sure about that, but it's conceivable when you're talking about how addressing works.
Last edited:
- Jan 20, 2010
- 17,561
- 8,861
- 79,540
I recently ran across a thread about this subject, over on the RWT forums. It's quite a long thread, but I was interested to see that Linus Torvalds had weighed in, at a few points. I always find his posts worth reading. He tends to highlight and focus on things which weren't even on my radar. He actually provided a very plausible explanation for why Intel stepped back from this move, which I haven't seen discussed here or in the article.
- https://www.realworldtech.com/forum/?threadid=221944&curpostid=221965
- https://www.realworldtech.com/forum/?threadid=221944&curpostid=221976
- https://www.realworldtech.com/forum/?threadid=221944&curpostid=222021
- https://www.realworldtech.com/forum/?threadid=221944&curpostid=222120
- https://www.realworldtech.com/forum/?threadid=221944&curpostid=222125
thestryker
Splendid
- Apr 19, 2016
- 4,691
- 2,978
- 30,690
After reading through that I think it's actually the most likely reason that doesn't involve the new x86 advisory group.
Side note: I didn't know about iAPX 432 and now I wish I didn't after reading through the general design details. I understand what they were trying to do, but yikes from a general compute standpoint.
- Jan 20, 2010
- 17,561
- 8,861
- 79,540
I wasn't really familiar with it, either. I read a bit of the Wikipedia page for it, just now, and would have to agree that it did sound like something of a debacle.
Their ambitions seemed outsized, relative to their tools & transistor budget. It does make me wonder what a more competent implementation might've looked like.
That said, it reminds me of 1980's era LISP Machines. I knew someone who once worked at Symbolics, and he said that when they took their OS and ported it to run on a modern RISC CPU, it ran significantly faster than on their custom hardware that was ostensibly designed to cater for it. On that basis, he advocated to ditch the custom hardware and just become a software company, but he lost that battle.
BTW, I've got to say I was a little surprised at the hard line Linus took against x86 Protected Mode segments. I knew Linux preferred to use virtual memory as a protection mechanism and I can see his points about the extra hoops the CPU must jump through because of the segmentation mechanism (whether or not you're using it as originally intended). It still does surprise me, a little bit, that he has so much animosity towards them. Back when I read a book on the 80386, I definitely drank the kool-aid on protected mode segments. I want to say it was this book, but the cover doesn't look quite like I remember. I sort of wish I still had my copy, at least so I could know whether mine was co-authored by Pat Gelsinger.
Last edited:
TRENDING THREADS
-
-
News RTX 5090 FE unboxing reveals eco-friendly packaging — an inkless box made of "paper fibers- Started by Admin
- Replies: 35
-
Question Bad performance with Rx 7600 XT and Ryzen 5 5500
- Started by Shaldon
- Replies: 4
-
Discussion PSU recommendations and power supply discussion thread - Tom's hardware- Started by Darkbreeze
- Replies: 2K
-
Discussion What's your favourite video game you've been playing?- Started by amdfangirl
- Replies: 4K
-
News AMD says Intel's 'horrible product' is causing Ryzen 9 9800X3D shortages
- Started by Admin
- Replies: 93
Facebook
Twitter
Instagram