3 ms·

I came across an interesting fact about X86, > currently there are actually no modern x86 CPUs on the market. Both Intel and AMD don't actually use x86 cores,

by frfl 3y ago

I came across an interesting fact about X86, > currently there are actually no modern x86 CPUs on the market. Both Intel and AMD don't actually use x86 cores, but instead proprietary RISC cores, with microcode that translates the x86 code to RISC code on the fly at execution time. https://cs.stackexchange.com/questions/132211/what-are-the-advantages-of-x86-cpus-over-arm https://cs.stackexchange.com/questions/132211/what-are-the-a... This cs.stackexchange link is a good read. Wikipedia also states something similar, > In the P6 and later microarchitectures, x86 instructions are internally converted into simpler RISC-style micro-operations that are specific to a particular processor and stepping level https://en.wikipedia.org/wiki/Intel_Microcode https://en.wikipedia.org/wiki/Intel_Microcode

jerf 3y ago
Also, the more transistors we stuff on to a chip, a process that is still continuing, the less are proportionally dedicated to these decoding pipelines. My impression is that they are already relatively insignificant parts of the chips, though corrections welcome. I wonder if there's any ISA that could be written against the x86 cores that would be more efficient. In theory the chip could use that as a mode, so the chip itself wouldn't require an entire OS to shift before things could use it. I don't know anywhere near enough about the inside of an x86 core to have even a clue if such a thing would be possible. But it would be an interesting escape hatch from x86. Anyone who can flesh this idea out with knowledge of the x86 core internals is welcome to explain to me why my idea is bad and I should feel bad.
kryptiskt 3y ago
By that account, there never has been any x86 CPU, since the OG 8086 had a microcode ROM and translated most instructions into micro-ops.
sjsdaiuasgdia 3y ago
> currently there are actually no modern x86 CPUs on the market. This feels like one of the stranger "no true Scotsman" arguments I've ever run across. Even the 8086 had microcode that translated the instructions as generated by the compiler/programmer into the instructions that would be processed: http://www.righto.com/2022/11/how-8086-processors-microcode-engine.html http://www.righto.com/2022/11/how-8086-processors-microcode-... I would love to know what the person who wrote that stackexchange answer would say in response to the question, "so which x86 processors used 'real' x86 cores?" Because from the very beginning of x86, there's been translation of the front-door opcodes into internal opcodes via microcode.
QuadmasterXLII 3y ago
Note that you couldn't directly simplify the architecture by just writing an assembler for the RISC microcode. The reason is that the RISC microcode is much larger than the x86 it is derived from. This on the fly decompression does wonders for cache hit percentage.
- snvzz 3y ago
  There's no RISC microcode. RISC is about the ISA, which is the interface between software and hardware. It is irrelevant whether the hardware is implemented with microops or hamsters running on wheels. Yet if the existing microops used in popular CPUs made today were actually exposed as the interface between software and hardware, they would be VLIW ISAs, not RISC ISAs. The whole "CISC have a RISC inside" idea is thus wrong at many levels, and just left over cultural damage from an Intel PR campaign ("risc vs cisc doesn't matter"), which was very effective at misinforming the tech world. Note that Intel chips did no-doubt win in the market, but that was despite CISC, rather than thanks to CISC: Intel had a MASSIVE fab advantage, alongside the software moat around Microsoft OSs.
gpderetta 3y ago
It seems I make this comment every 6 months or so, but... x86 uops are not at all RISC-style. They are very large (classic RISC uses 32bit encoding, uops are over 100 bits), variable size (classic RISC is fixed style, uops can use multiple slots to encode constants) and can encode load-op (classic RISC separates load and stores from operations). There is also the fact that RISC-ness is a property of the ISA, so applying it to describe a microarchitecture doesn't make much sense. edit: reference: https://www.quora.com/Why-are-RISC-processors-considered-faster-than-CISC-processors/answer/Bob-Colwell-1 https://www.quora.com/Why-are-RISC-processors-considered-fas... (sorry for the quora link)
samsartor 3y ago
> Intel and AMD don't use x86 cores but [...] instead translate the x86 code to RISC code on the fly I used to say this all the time and I've been informed that it's something of a misunderstanding. For example, most RISC-V processors also decompose instructions into multiple μops: https://docs.boom-core.org/en/latest/sections/execution-stages.html https://docs.boom-core.org/en/latest/sections/execution-stag... So it isn't like there is a literal RISC processor inside the x86 processor with a tiny little compiler sitting in the middle. It's just that the out-of-order execution model requires instructions to be broken up into subtasks which can separately queue at the core's various execution units. Even pipelining instructions still wastes a lot of silicon (while you're doing an integer add the floating point ALU is just sitting there, bored) so breaking things up this way greatly improves parallelism. As I understand it, modern μop-based processor cores can actually have dozens of ALUs, multiple load/store units, virtual->physical address translation units, etc all working together asynchronously to chug through the incoming instructions.
jcranmer 3y ago
> currently there are actually no modern x86 CPUs on the market. Both Intel and AMD don't actually use x86 cores, but instead proprietary RISC cores, with microcode that translates the x86 code to RISC code on the fly at execution time. This kind of factoid does more to obscure the truth than it does to illuminate it. The truth of the matter is that all high-end CPUs do a µop translation, whether or not their frontend is a CISC or RISC ISA. Indeed, the very notion of CISC versus RISC is way overwrought in architecture textbooks, and this probably produces the garbled thinking: since everyone "knows" that CISC can't be superscalar, this means that the Pentium (in making superscalar x86) has to somehow be RISC. Another thing to note is that there's not really anything called CISC. RISC is the overall term for a family of computer architecture design methodologies arising the 80's that argued for compiler-centric rather than assembler-centric design and simpler instructions, sometimes to the point that you omit hardware and call it a feature (e.g., delay slots). CISC is... everything else; it's a strawman constructed for RISC to compete against rather than a coherent design methodology. In actual practice, though, RISC v CISC hasn't been relevant for decades. Some of the RISC design ideas have won out: there's generally a high emphasis on instructions that can be selected by the compiler over hand-tuned assembly, for example. But things like delay slots have been generally considered a failure. The architectures that are the most successful--x86 and ARM--are the ones that blur the line between RISC and CISC the most. Actually, if you scrubbed the x86 assembly away and came up with some new assembly syntax (including new mnemonics of course), you could probably sell the x86 ISA as a "compressed RISC" ISA and get many people to believe you that it was designed as a RISC. x86 doesn't have many instructions that have crazy interrupt rules or multiple memory references (the string instructions are the main exceptions here), and it's this property which turns out to be really key to making something high-performance or not. It would be better for us to be honest about what enables or doesn't enable superscalar architectures rather than trying to argue that somehow x86 cheated its way to success.
- StressedDev 3y ago
  Thank you for saying this. The amount of hype RISC gets in unbelievable. It is especially irritating because almost every major RISC design which came out of the 1980s and early 1990s failed in the market. PA RISC is dead. PowerPC, MIPS and Spark are either on life support or only used in cheap low cost or maybe low power products. I believe IBM's Power architecture is still going but I suspect it's slower than AMD's and Intel's x86 chips (IBM does not publish SPEC CPU Benchmark results which is not a good sign). Basically, I have noticed that people have been claiming RISC is the best for decades and yet real RISC architectures failed to beat x86's performance. Even worse, most of the RISC workstation and server makers exited the business, went bankrupt, or only sell systems to legacy customers who have not migrated to x86.
imtringued 3y ago
There are two ways to interpret this statement. First is that ISA is completely irrelevant since you can just convert to whatever is best. This is bad for RISC since there is literally no advantage gained by losing backwards compatibility. The other interpretation is that micro ops are actually a microarchitectural optimization and that RISC processors should use it too. The compressed instruction set of RISC-V is leaning towards that direction. RISC-V processors internally convert RISC-V instructions to RISC-V. It is kind of hollow to talk about it, since it is hardly clear to say that this is a unique disadvantage or advantage.
- snvzz 3y ago
  >This is bad for RISC since there is literally no advantage gained by losing backwards compatibility. I respectfully disagree. There's a major advantage of losing backwards compatibility with established ISAs, and that is freedom from licensing. e.g. The main strength of RISC-V is not even its technical superiority; It is the free license.

by frfl 3y ago

jerf 3y ago

Also, the more transistors we stuff on to a chip, a process that is still continuing, the less are proportionally dedicated to these decoding pipelines. My impression is that they are already relatively insignificant parts of the chips, though corrections welcome. I wonder if there's any ISA that could be written against the x86 cores that would be more efficient. In theory the chip could use that as a mode, so the chip itself wouldn't require an entire OS to shift before things could use it. I don't know anywhere near enough about the inside of an x86 core to have even a clue if such a thing would be possible. But it would be an interesting escape hatch from x86. Anyone who can flesh this idea out with knowledge of the x86 core internals is welcome to explain to me why my idea is bad and I should feel bad.

kryptiskt 3y ago

By that account, there never has been any x86 CPU, since the OG 8086 had a microcode ROM and translated most instructions into micro-ops.

sjsdaiuasgdia 3y ago

> currently there are actually no modern x86 CPUs on the market. This feels like one of the stranger "no true Scotsman" arguments I've ever run across. Even the 8086 had microcode that translated the instructions as generated by the compiler/programmer into the instructions that would be processed: http://www.righto.com/2022/11/how-8086-processors-microcode-engine.html http://www.righto.com/2022/11/how-8086-processors-microcode-... I would love to know what the person who wrote that stackexchange answer would say in response to the question, "so which x86 processors used 'real' x86 cores?" Because from the very beginning of x86, there's been translation of the front-door opcodes into internal opcodes via microcode.

QuadmasterXLII 3y ago

Note that you couldn't directly simplify the architecture by just writing an assembler for the RISC microcode. The reason is that the RISC microcode is much larger than the x86 it is derived from. This on the fly decompression does wonders for cache hit percentage.

snvzz 3y ago
There's no RISC microcode. RISC is about the ISA, which is the interface between software and hardware. It is irrelevant whether the hardware is implemented with microops or hamsters running on wheels. Yet if the existing microops used in popular CPUs made today were actually exposed as the interface between software and hardware, they would be VLIW ISAs, not RISC ISAs. The whole "CISC have a RISC inside" idea is thus wrong at many levels, and just left over cultural damage from an Intel PR campaign ("risc vs cisc doesn't matter"), which was very effective at misinforming the tech world. Note that Intel chips did no-doubt win in the market, but that was despite CISC, rather than thanks to CISC: Intel had a MASSIVE fab advantage, alongside the software moat around Microsoft OSs.

gpderetta 3y ago

It seems I make this comment every 6 months or so, but... x86 uops are not at all RISC-style. They are very large (classic RISC uses 32bit encoding, uops are over 100 bits), variable size (classic RISC is fixed style, uops can use multiple slots to encode constants) and can encode load-op (classic RISC separates load and stores from operations). There is also the fact that RISC-ness is a property of the ISA, so applying it to describe a microarchitecture doesn't make much sense. edit: reference: https://www.quora.com/Why-are-RISC-processors-considered-faster-than-CISC-processors/answer/Bob-Colwell-1 https://www.quora.com/Why-are-RISC-processors-considered-fas... (sorry for the quora link)

samsartor 3y ago

> Intel and AMD don't use x86 cores but [...] instead translate the x86 code to RISC code on the fly I used to say this all the time and I've been informed that it's something of a misunderstanding. For example, most RISC-V processors also decompose instructions into multiple μops: https://docs.boom-core.org/en/latest/sections/execution-stages.html https://docs.boom-core.org/en/latest/sections/execution-stag... So it isn't like there is a literal RISC processor inside the x86 processor with a tiny little compiler sitting in the middle. It's just that the out-of-order execution model requires instructions to be broken up into subtasks which can separately queue at the core's various execution units. Even pipelining instructions still wastes a lot of silicon (while you're doing an integer add the floating point ALU is just sitting there, bored) so breaking things up this way greatly improves parallelism. As I understand it, modern μop-based processor cores can actually have dozens of ALUs, multiple load/store units, virtual->physical address translation units, etc all working together asynchronously to chug through the incoming instructions.

jcranmer 3y ago

> currently there are actually no modern x86 CPUs on the market. Both Intel and AMD don't actually use x86 cores, but instead proprietary RISC cores, with microcode that translates the x86 code to RISC code on the fly at execution time. This kind of factoid does more to obscure the truth than it does to illuminate it. The truth of the matter is that all high-end CPUs do a µop translation, whether or not their frontend is a CISC or RISC ISA. Indeed, the very notion of CISC versus RISC is way overwrought in architecture textbooks, and this probably produces the garbled thinking: since everyone "knows" that CISC can't be superscalar, this means that the Pentium (in making superscalar x86) has to somehow be RISC. Another thing to note is that there's not really anything called CISC. RISC is the overall term for a family of computer architecture design methodologies arising the 80's that argued for compiler-centric rather than assembler-centric design and simpler instructions, sometimes to the point that you omit hardware and call it a feature (e.g., delay slots). CISC is... everything else; it's a strawman constructed for RISC to compete against rather than a coherent design methodology. In actual practice, though, RISC v CISC hasn't been relevant for decades. Some of the RISC design ideas have won out: there's generally a high emphasis on instructions that can be selected by the compiler over hand-tuned assembly, for example. But things like delay slots have been generally considered a failure. The architectures that are the most successful--x86 and ARM--are the ones that blur the line between RISC and CISC the most. Actually, if you scrubbed the x86 assembly away and came up with some new assembly syntax (including new mnemonics of course), you could probably sell the x86 ISA as a "compressed RISC" ISA and get many people to believe you that it was designed as a RISC. x86 doesn't have many instructions that have crazy interrupt rules or multiple memory references (the string instructions are the main exceptions here), and it's this property which turns out to be really key to making something high-performance or not. It would be better for us to be honest about what enables or doesn't enable superscalar architectures rather than trying to argue that somehow x86 cheated its way to success.

StressedDev 3y ago
Thank you for saying this. The amount of hype RISC gets in unbelievable. It is especially irritating because almost every major RISC design which came out of the 1980s and early 1990s failed in the market. PA RISC is dead. PowerPC, MIPS and Spark are either on life support or only used in cheap low cost or maybe low power products. I believe IBM's Power architecture is still going but I suspect it's slower than AMD's and Intel's x86 chips (IBM does not publish SPEC CPU Benchmark results which is not a good sign). Basically, I have noticed that people have been claiming RISC is the best for decades and yet real RISC architectures failed to beat x86's performance. Even worse, most of the RISC workstation and server makers exited the business, went bankrupt, or only sell systems to legacy customers who have not migrated to x86.

imtringued 3y ago

There are two ways to interpret this statement. First is that ISA is completely irrelevant since you can just convert to whatever is best. This is bad for RISC since there is literally no advantage gained by losing backwards compatibility. The other interpretation is that micro ops are actually a microarchitectural optimization and that RISC processors should use it too. The compressed instruction set of RISC-V is leaning towards that direction. RISC-V processors internally convert RISC-V instructions to RISC-V. It is kind of hollow to talk about it, since it is hardly clear to say that this is a unique disadvantage or advantage.

snvzz 3y ago
>This is bad for RISC since there is literally no advantage gained by losing backwards compatibility. I respectfully disagree. There's a major advantage of losing backwards compatibility with established ISAs, and that is freedom from licensing. e.g. The main strength of RISC-V is not even its technical superiority; It is the free license.