The legend of “x86 CPUs decode instructions into RISC form internally” (2020)

I&#x27;ve never liked this idea that <i>x86 CPUs decode instructions into RISC form internally</i>. Before there was RISC, before there was even x86, there were microcoded instruction sets [1]. They were first implemented in Wilkes&#x27; 1958 EDSAC 2. Indeed the Patterson Ditzel paper even comments on this:<p><pre><code> Microprogrammed control allows the implementation of complex architectures more cost-effectively than hardwired control. [2] </code></pre> These horizontally microprogrammed instructions interpreted the architectural instruction set. The VAX 11&#x2F;750 microcode control program had an interpreter loop. There could be more than 100 bits in these horizontal instructions with 30+ fields. Horizontally microprogrammed instructions were not in any way <i>reduced</i>. Indeed, reduction would mean paying the decode tax twice.<p>There was another form, vertical microprogramming, which was closer to RISC. But there was no translation from complex to vertical.<p>[1] <a href="https:&#x2F;&#x2F;www.cs.princeton.edu&#x2F;courses&#x2F;archive&#x2F;fall10&#x2F;cos375&#x2F;BestWay.pdf" rel="nofollow noreferrer">https:&#x2F;&#x2F;www.cs.princeton.edu&#x2F;courses&#x2F;archive&#x2F;fall10&#x2F;cos375&#x2F;B...</a><p>[2] <a href="https:&#x2F;&#x2F;inst.eecs.berkeley.edu&#x2F;~n252&#x2F;paper&#x2F;RISC-patterson.pdf" rel="nofollow noreferrer">https:&#x2F;&#x2F;inst.eecs.berkeley.edu&#x2F;~n252&#x2F;paper&#x2F;RISC-patterson.pd...</a>

It is fascinating that semantic confusion over RISC vs CISC persists since I was in college in the 80&#x27;s. It is largely meaningless.<p>The naive idea behind RISC is essentially to reduce the ISA to near-register-level operations: load, store, add, subtract, compare, branch. This is great for two things: being the first person to invent an ISA, and teaching computer engineering.<p>Look at the evolution of RISC-V. The intent was to build an open source ISA from a 100% clean slate, using the world&#x27;s academic computer engineering brains (and corporations that wanted to be free of Arm licensing) ... and a lot of the subtext was initially around ISA purity.<p>Look at the ISA today, specifically the RISC-V extensions that have been ratified. It has a soup of wacky opcodes to optimize corner cases, and obscure vendor specific extensions that are absolutely CISC-y (examine T-Head&#x27;s additions if you don&#x27;t believe me!).<p>Ultimately the combination of ISA, implementation (the CPU), and compiler struggle to provide optimal solutions for the majority of applications. This inevitably leads to a complex instruction set computer. Put enough engineers on the optimization problem and that&#x27;s what happens. It is not a good or bad thing, it just IS.

What I find most interesting is the &quot;social history&quot; of RISC vs CISC: how did a computer architecture issue from the 1980s turn into something that people vigorously debate 40 years later?<p>I have several theories:<p>1. x86 refused to die as expected, so the RISC vs CISC debate doesn&#x27;t have a clear winner. There are reasonable arguments that RISC won, CISC won, or it no longer matters.<p>2. RISC vs CISC has clear teams: now Apple vs Intel, previously DEC, Sun, etc vs Intel. So you can tie the debate into your &quot;personal identity&quot; more than most topics. The debate also has an underdog vs entrenched monopoly vibe that makes it more interesting.<p>3 RISC vs CISC is a simple enough topic for everyone to have an opinion (unlike, say, caching policies). But on the other hand, it&#x27;s vague enough that nobody can agree on anything.<p>4. RISC exists on three levels: First, a design philosophy &#x2F; ideology. Second, a style of instruction set architecture that results from this philosophy. Finally, a hardware implementation style (deep pipelines, etc) that results. With three levels for discussion, there&#x27;s lots of room for debate.<p>5. RISC vs CISC has a large real-world impact, not just for computer architects but for developers and users. E.g. Apple switching to ARM affects the user but changing the internal bus architecture does not.<p>(I&#x27;ve been trying to make a blog post on this subject, but it keeps spiraling off in random directions.)

No mention of AMD&#x27;s RISC86 which was the patented internal decoding of X86 instructions into a RISC instruction set.<p><a href="https:&#x2F;&#x2F;patents.google.com&#x2F;patent&#x2F;US5926642A&#x2F;en" rel="nofollow noreferrer">https:&#x2F;&#x2F;patents.google.com&#x2F;patent&#x2F;US5926642A&#x2F;en</a> (1996)

If someone says x86 decodes to RISC internally, they might be getting at one of two different ideas:<p>(1) RISC really is the fastest&#x2F;best way for CPUs to operate internally.<p>(2) x86 performance isn&#x27;t held back (much) by its outmoded instruction set.<p>x86 architectures were for a while translating into effectively RISC but stopped doing it. Now internally they are less RISC-like. This suggests #1 is false and #2 is true.<p>They could if they want to (because they have) but they don&#x27;t want to anymore. Presumably because it&#x27;s not the best way to do it. Although I guess it could be slightly better but not worth the cost of translating.

I&#x27;m not sure how true this is or if it&#x27;s a legend but I remember reading about this originating from Intel marketing in response to the rise of the popularity of RISC in the 1990s.<p>In essence it intended to give the impression that there is no need for RISC architecture because x86 was already a RISC behind the scenes. So you got the best of both worlds.

&quot;RISC&quot; architectures are doing something effectively identical to uop fusion though. The real myth is the idea of a CISC&#x2F;RISC dichotomy in the first place when frankly that notion only ever applied to the ISA specifications and not (except for the very earliest cores) CPU designs.<p>In point of fact beyond the instruction decode stage all modern cores look more or less identical.

&gt;Final verdict<p>&gt;There is some truth to the story that x86 processors decode instructions into RISC-like form internally. This was, in fact, pretty much how P6 worked, later improvements however made the correspondence tortuous at best. Some microarchitecture families, on the other hand, never did anything of the sort, meaning it was never anywhere near a true statement for them.

A question that maybe HN can help me answer: are there <i>any</i> new instruction set architectures since, say, 1985 that are CISC? (Excluding, of course, ISAs that are extensions of previous CISC ISAs.)

Somewhat related: <a href="http:&#x2F;&#x2F;danluu.com&#x2F;new-cpu-features&#x2F;" rel="nofollow noreferrer">http:&#x2F;&#x2F;danluu.com&#x2F;new-cpu-features&#x2F;</a> discussion: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=31093430">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=31093430</a>

&quot;(the code is 32-bit just to allow us to discuss very old x86 processors)&quot;<p>fsck, that hurts.

I&#x27;m not sure how you could write something like this without considering something like the micro op cache, which is present in all modern x86 and some arm processors. The micro op cache on x86 is effectively is the only way an x86 processor can get full ipc performance, and that&#x27;s because it contains pre decoded instructions. We don&#x27;t know the formats here, but we can guarantee that they are fixed length instructions and that they have branch instructions annotated. Yeah sure, these instructions have more complicated semantics than true risc instructions, but they have the most important part - fixed length. This makes it possible for 8-10 of them to be dispatched to the backend per cycle. In my mind, this definitely is the &quot;legend&quot; manifested.

No mention of RISC86[1] and the hype[2] surrounding it.<p>[1] <a href="https:&#x2F;&#x2F;patents.google.com&#x2F;patent&#x2F;US6336178B1&#x2F;en" rel="nofollow noreferrer">https:&#x2F;&#x2F;patents.google.com&#x2F;patent&#x2F;US6336178B1&#x2F;en</a><p>[2] <a href="https:&#x2F;&#x2F;halfhill.com&#x2F;byte&#x2F;1996-1_amd-k6.html" rel="nofollow noreferrer">https:&#x2F;&#x2F;halfhill.com&#x2F;byte&#x2F;1996-1_amd-k6.html</a>

Needs (2020). It explains why, for example, Zen 2 &amp; 3 are not discussed.

Saved this great article from a couple of years ago, <a href="https:&#x2F;&#x2F;medium.com&#x2F;swlh&#x2F;what-does-risc-and-cisc-mean-in-2020-7b4d42c9a9de" rel="nofollow noreferrer">https:&#x2F;&#x2F;medium.com&#x2F;swlh&#x2F;what-does-risc-and-cisc-mean-in-2020...</a>

The splitting of &quot;store address&quot; and &quot;store data&quot; is an intentional performance feature and not a &quot;quirk&quot; of the implementation. If you had a single store uop then the memory system couldn&#x27;t start doing a lookup on the address until the data to be stored was available. The data is usually the long pole. By having the address in a separate uop the data dependency is broken and the cache accesses allocating that line in the cache can be started much sooner.

One woman’s RISC is another man’s CISC. The “perform operation and branch on flags” operation described here might not be part of RISC-V, but it 100% was part of ARM 1 when ARM was at the forefront of the movement.

The &quot;Final Verdict&quot; is very plain and is hardly enhanced by reading the body of the article. It would make more sense if it was put in the opening of the article, creating a complete abstract.

Related:<p><a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=27334855">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=27334855</a><p><a href="https:&#x2F;&#x2F;www.google.com&#x2F;search?q=%22christopher+domas%22+x86+%22god+mode%22" rel="nofollow noreferrer">https:&#x2F;&#x2F;www.google.com&#x2F;search?q=%22christopher+domas%22+x86+...</a><p><a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Alternate_Instruction_Set" rel="nofollow noreferrer">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Alternate_Instruction_Set</a><p>&gt;&quot;In 2018 Christopher Domas discovered that some Samuel 2 processors came with the Alternate Instruction Set enabled by default and that by executing AIS instructions from user space, it was possible to gain privilege escalation from Ring 3 to Ring 0.[5] Domas had partially reverse engineered the AIS instruction set using automated fuzzing against a cluster of seven thin clients.[12] Domas used the terms &quot;deeply embedded core&quot; (DEC) plus &quot;deeply embedded instruction set&quot; (DEIS) for the RISC instruction set, &quot;launch instruction&quot; for JMPAI, &quot;bridge instruction&quot; for the x86 prefix wrapper, &quot;global configuration register&quot; for the Feature Control Register (FCR), and documented the privilege escalation with the name &quot;Rosenbridge&quot;.[5]&quot;<p>Also -- I should point out that the debate of <i>if</i> x86 (CISC) CPU&#x27;s contain RISC cores -- is largely academic.<p>Both RISC and CISC CPU&#x27;s contain ALU&#x27;s -- so our only debate, really, if we have one, is <i>how</i> exactly data that the ALU is going to process -- is going to wind up at the ALU...<p>It is well known in the x86 community that the x86 instructions are an abstraction, a level of abstraction which runs on top of lower-level of abstraction, the x86 microcode layer...<p>Historically, intentionally or unintentionally, most x86 vendors have done everything they can to hide, obfuscate, and obscure this layer... There (to the best of my knowledge, at this point in time) is no official documentation of this layer, how it works (etc., etc.) from any any major x86 vendor.<p>x86 microcode update blobs -- are binary &quot;black boxes&quot; and encrypted.<p>Most of our (limited) knowledge in this area comes from various others who have attempted to understand the internal workings of x86 microcode:<p><a href="https:&#x2F;&#x2F;www.google.com&#x2F;search?q=%22reverse+engineering+x86+processor+microcode%22" rel="nofollow noreferrer">https:&#x2F;&#x2F;www.google.com&#x2F;search?q=%22reverse+engineering+x86+p...</a><p><a href="https:&#x2F;&#x2F;github.com&#x2F;RUB-SysSec&#x2F;Microcode">https:&#x2F;&#x2F;github.com&#x2F;RUB-SysSec&#x2F;Microcode</a><p><a href="https:&#x2F;&#x2F;twitter.com&#x2F;_markel___&#x2F;status&#x2F;1262697756805795841" rel="nofollow noreferrer">https:&#x2F;&#x2F;twitter.com&#x2F;_markel___&#x2F;status&#x2F;1262697756805795841</a><p><a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=lY5kucyhKFc">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=lY5kucyhKFc</a><p>It should be pointed out that even if a complete understanding of x86 microcode were to be had for one generation of CPU -- there would always be successive generations where that implementation might change -- leaving anyone who would wish to fully understand it, back at square one...<p>To (mis)quote Douglas Adams:<p><i>&quot;There is a theory which states that if ever anyone discovers exactly what the x86 microcode layer is for and why it is here, it will instantly disappear and be replaced by something even more bizarre and inexplicable.&quot;<p>There is another theory which states that this has already happened.&quot;</i> :-) &lt;g&gt;

I grew up in the 80s and 90s, and what I gathered from listening to the grey beards talk was that RISC based designs were more elegant, easier to understand, and more efficient. When I first started hearing about then modern CISC cpus decoding to RISC, it was pushed as a justification that RISC was fundamentally superior.<p>This was around the time IBM was pushing Power and everyone thought it was poised to dominate the industry.

There are some similarities with Transmeta.

The main issue with Intel&#x27;s CISC&#x2F;&quot;RISC&quot; Like Execution Engine is that it takes more transistors to implement that and the Instruction Decoders are huge relative to any ARM&#x2F;RISC like ISA that has the majority of the ARM ISA Assembly Language Instructions actually translated directly to the Micro-OP format on a one to one basis, assembly language instruction to micro-op instruction. So for the x86 ISA that has most of its assembly language instructions decode into multiple micro-ops on a one to many basis there and that&#x27;s a more energy intensive process there. And more transistors used to implement all that on the x86 designs use more power and leak more power as well.<p>It takes many times that die area to Implement a full x86 ISA Instruction Decoder compared to and ARM 64 bit only Instruction Decoder and its fewer numbers of total instructions there on say the Apple A14&#x2F;Firestorm core where Apple could easily fit 8 ARM 64 bit ISA Instruction Decoders on the A14&#x2F;Later Performance core designs! So the A14&#x2F;Later wide decode there is 8 Instructions Decoded per cycle and all that feeds into a ridiculously large reorder buffer to extract more instruction level parallelism and get that dispatched to a very wide array of execution ports.<p>So and x86 core has to be much larger there and most of that is currently 6 or less Instruction Decoders wide with AMD being only 4 Instruction Decoders wide the with Zen-4&#x2F;Earlier and Intel Being 6 wide with Golden Cove that&#x27;s got only One complex x86 decoder and 5 &quot;Simple&quot; x86 decoders on that design that the tech press has never deep dived the difference there Complex&#x2F;Simple in that Golden Cove Instruction Decoder design.<p>But the x86 cores are usually clocked around 2GHz higher than Apple&#x27;s A14&#x2F;Later cores in Apple&#x27;s M series SOC designs and really are nowhere near as power efficient as the RISC cores there as the x86 cores are narrower and have lower IPC relative to the A14&#x2F;Later Apple cores that are extra wide and high IPC in design that can be clocked well inside their Performance&#x2F;Watt sweet spot range on laptops and have the best battery life metrics on the consumer market. And that&#x27;s compared to the x86 cores that have to be clocked higher there and outside their Performance&#x2F;Watt sweet spots where the x86 designs have to be down-clocked on battery power there whereas as the M series Apple laptops run at the same clocks on mains power or battery power.<p>Talk all you want about CISC and RISC but the simpler Instruction Sets of the RISC designs allow for more room for wider ranks of Instruction Decoders on the Custom ARM core designs that send that to wider execution dispatch there to ALUs, and other execution ports that are all 64 bits mostly(Neon and AVX aside) now that get the same work done only that&#x27;s wider there for the custom ARM designs from Apple that have such high IPC that the processors can be clocked well inside their Performance&#x2F;Watt sweet spots unlike the narrow x86 cores that have to get clocked well outside their Performance&#x2F;Watt sweet spots to achieve a similar single core performance than the extra wide order superscalar A14&#x2F;Later Apple designs.<p>And Apple&#x27;s A14&#x2F;Later core designs can be used in Smartphones&#x2F;Tablets and Laptop&#x2F;PC as well unlike the x86 designs that never really made inroads into that smartphone market. So actually is the ability of the RISC ISA processors to be made wider order superscalar there to get more done per clock cycle and well inside the Performance&#x2F;Watt sweet spots there on whatever process node utilized!

RISC just means that the instruction set is <i>reduced</i> (compared to what was the norm in the early 1980s). It does not say whether the architecture is register-memory or load-store (though most RISC ISAs are load-store). As long as the x86 CPUs does not decode to more than, say, two dozen microcode <i>types</i> it uses RISC &quot;internally&quot;.

Some actually do use something resembling an actual RISC core --- the VIA Alternate Instruction Set (<a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Alternate_Instruction_Set" rel="nofollow noreferrer">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Alternate_Instruction_Set</a>) basically exposes the uop format, and if you look at the documentation, you&#x27;ll find that it&#x27;s like they took a MIPS core and stripped out irrelevant instructions while adding other ones more useful to x86; even the opcode map and encoding is identical for the instructions that remained.<p>IMHO the RISC vs CISC debate was never about implementation, only ISA. Even the 8086 uses a combination of microcoded and non-microcoded instructions (<a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=35939168">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=35939168</a>).<p>Also, calling it a &quot;legend&quot; in the title is rather clickbaity.