The legend of “x86 CPUs decode instructions into RISC form internally” (2020)
fanael.github.io
fanael.github.io
Microprogrammed control allows the implementation of complex architectures more cost-effectively than hardwired control. [2]
There was another form, vertical microprogramming, which was closer to RISC. But there was no translation from complex to vertical.
[1] https://www.cs.princeton.edu/courses/archive/fall10/cos375/B...
[2] https://inst.eecs.berkeley.edu/~n252/paper/RISC-patterson.pd...
And current x86 still implement some instructions via microcode. Some are even performance sensitive (eg rep movsb)
If you ensure the indexes are actually multiple microinstructions away from each other (for example, shift opcode to upper part of uOP program counter) you can easily map multiple uOPs when necessary without branching into more complex microcode.
What exactly we mean by "RISC" and "CISC" becomes important here. If, by RISC, we mean an architecture without complex addressing modes, then "CISCs are just RISCs with a fancy decoder" is wrong. But if we expand our definition of "RISC" to allow for complex addressing modes and stuff, but keep a vague upper limit on the "amount of stuff" the instruction can do, it's sort of more appropriate; the "CISCy" REPNZ SCASB instruction (basically a strlen-instruction) is certainly decoded into a loop of less complex instructions.
I think the main issue with most of these discussions is in the very idea that there is such a thing as "RISC" and "CISC", when there's no such distinction. They are, at best, abstract philosophies around ISA design which describe a general preference for complex instructions vs simpler instructions, where even the terms "complex" and "simple" have very muddy definitions.
TL;DR: I agree
This is true for all mainstream implementations of RISC-V, Alpha [1], and MIPS.
To whatever extent a "RISC" core decodes (some) instructions into µops, it is deviating from RISC.
ARM has always had mixed designs, marketed as "RISC".
x86 is the least CISCy of the CISC ISAs. Except for the string instructions, it has only one memory operand in each instruction, and the addressing modes are simple with at most two registers (one scaled) plus a constant. In particular (unlike most CISC and indeed most pre-CISC/RISC ISAs) there is no indirect addressing.
If you are looking at x86 as representative of CISC and ARM as representative of RISC and saying "there is hardly any difference" then 1) you are correct, and 2) you are looking a neither true CISC nor true RISC -- both of which do actually exist.
[1] with one exception on some cores: cmov
It’s more accurate to say that there will be a 1-to-1 relationship between RISC-V instructions and uops, but there’s a push to perform fusion for some instructions, so even that may not actually be true either.
There are zero currently shipping commercially-produced RISC-V CPUs that do instruction-fusing -- and we know more than 10 billion cores had been shipped as at this time last year.
The three or four companies currently designing RISC-V CPUs intended to be competitive with current or near-current x86 and Apple are of course making 8-wide (or so) OoO cores, and they say they are implementing some instruction fusion.
Those will be available in two or three years perhaps, and will get a lot of publicity, but they will be a tiny minority of RISC-V cores shipped, just as Cortex-A and Cortex-X are a tiny minority of Arm's.
This is like arguing that RISC-V doesn’t need advanced branch predictors because MCUs done need them.
That’s not very accurate either. Most instructions are not implemented in microcode. Only rare or complex instructions are.
What exactly comprises the Intel CPU microcode is somewhat of a mystery, but I also remember somebody tearing apart the blob with the Spectre or Meltdown mitigation and posting the findings (a guesswork, in fact) of what was in there. The microcode was very low level, and it was not very comprehensible to me.
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.
Look at the evolution of RISC-V. The intent was to build an open source ISA from a 100% clean slate, using the world'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.
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's additions if you don't believe me!).
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's what happens. It is not a good or bad thing, it just IS.
Also, define strong memory model. This is the first time I hear that memory model can be strong.
And, finally, define what is "simple" in instruction set.
But it is a no-go for SMP scalability.
That's why most architectures today use weak ordering.
x86 is alone and a dinosaur.
x86 has also illustrated the triangle, garnering some weakly ordered benefits with examples like avx512 and enhanced rep movsb.
The interesting thing is both solutions (weak ordering, special instructions) have been largely left to the compiler to manage, so it could become a question of which the compiler is better able to leverage. For example, if people are comfortable programming MP code in C on a strong memory model but reach for python on a weak memory model, things could shake out differently than expected.
> But it is a no-go for SMP scalability.
The SPARC architecture introduced the TSO and defaults to the total store order, and SPARC (and later UltraSPARC) systems were one the first successful highly scaleable SMP implementations.
Sun Enterprise 10000 (E10k) servers could be configured with up to 64x CPU's (initially released in 1997), Sun Fire 15K (available in 2002) could support up to 106x CPU's, Sun Fire E25K released in 2004 could support up to 72x dual-core CPU's (144x CPU cores in total).
SPARC survives (albeit not frequently heard about today) as Oracle SPARC T8-4 and M8-8 (8x CPU's, 32x CPU cores each, 256 threads per core) and Fujitsu[0] SPARC M12-2S (32x CPU's, 384 cores on each CPU and 3072 CPU threads).
All of the above is SMP and very many CPU's, CPU cores and CPU threads.
A succeful, scaleable, SMP architecture has to get the cache coherence protocols right irrespective of whether the ISA implements the TSO, is weakly ordered or a hybrid approach.
To ensure the cache coherence in a TSO UltraSPARC SMP architecture, Sun E10k realised a threefold approach: 1) it broadcast cache coherence on a logical bus (as opposed to a physical bus) shaped as a tree where all CPU's were leaves with all links between them being point-to-point, 2) greater coherence request bandwidth could be achieved by using multiple logical buses, whilst still maintaining a total order of coherence requests (the E10k had four logical buses, and coherence requests were address-interleaved across them, and 3) data response messages, which are much larger than request messages, did not require the totally ordered broadcast network required for coherence requests.
The E10k scaled exceptionally well in its SMP setup whilst using the TSO. It was also highly performant in its prime time with the successor Sun Fire family improving even further.
Therefore, the strong memory ordering being a no-go for the SMP scalability statement is bunk.
[0] And Fujitsu has been a well known poster child of making massively scaleable, (Ultra-)SPARC based supercomputing systems for a very long time as well.
They are common in description of memory access orderings, but not memory model itself.
About the history of RISC, the basic idea dates to Seymour Cray's 1964 CDC 6600. I don't think Berkeley gives Cray enough credit.
The CDC 6600 [95] and Cray-1 [82] ISAs, in many respects the precursors to RISC, each had two lengths of instruction, albeit without the redundancy property of the Stretch.
Better to reserve and not finish that to be unprepared.
In any case, decimal floating point is better for MOST programs/programmers and is only inferior in being harder to implement (imo).
See openvpn as an example.
Complexity needs to be managed, not labelled and shunned because it is "too hard" or "ugly". That is life. Learn that early and it will help.
Every memory access can cause a trap, but CPUs seem to have no problem about it. The branch is very unlikely and can always be predicted as "not taken".
Get rid of what complexity you can then deal with the rest that you must have.
Yes, that idea was evaluated, weighted and discarded as harmful, and the details are referenced in the spec itself.
> We did not include special instruction-set support for overflow checks on integer arithmetic operations in the base instruction set, as many overflow checks can be cheaply implemented using RISC-V branches.
> For general signed addition, three additional instructions after the addition are required
Is this "cheap", replacing 1 instruction with four? According to some old mainframe era research (cannot find link now), addition is one of the most often used instructions and they suggest that we should replace each instruction with four?
Their "rationale" is not rational at all. It doesn't make sense.
Overflow check should be free (no additional instructions required), otherwise we will see the same story we have seen for last 50 years: compiler writers do not want to implement checks because they are expensive; language designers do not want to use proper arithmetic because it is expensive. And CPU designers do not want to implement traps because no language needs them. As a result, there will be errors and vulnerabilities. A vicious circle.
What also surprises me is that they added fused add-multiply instruction which can easily be replaced by 2 separate instructions, is not really needed in most applications (like a web browser), and is difficult to implement (if I am not mistaken, you need to read 3 registers instead of 2, which might require additional ports in register file only for this useless instruction).
[1] https://github.com/riscv/riscv-isa-manual/releases/download/...
How do people do overflow checking on x86 and ARM in practice? For languages which implement it, such as Rust or Ada?
I know 32-bit x86 has the INTO instruction, which raises interrupt 4 if the overflow flag (OF) is set – but it was removed in x86-64, which gives me the impression that even languages which did do checked arithmetic weren't using it.
> but against some imaginary ideal CPU that doesn't exist
I'm not the person you are responding to, but to try to read their argument charitably (to "steelman" it) – if a person thinks checked arithmetic is an important feature, RISC-V's decision not to include it could be seen as a missed opportunity.
> or no one uses because it's so slow.
Is it inherently slow? Or is it just the chicken-egg problem of hardware designers feel no motivation to make it fast because software doesn't use it, meanwhile software doesn't use it because the hardware doesn't make it fast enough?
> I know 32-bit x86 has the INTO instruction, which raises interrupt 4 if the overflow flag (OF) is set – but it was removed in x86-64, which gives me the impression that even languages which did do checked arithmetic weren't using it.
Languages still use the overflow flag, they just don't use interrupts. I'm most familiar with Rust, where if the program wants a boolean value representing overflow (e.g., with checked_* or overflowing_* operations), LLVM obtains that value using a SETO or SETNO instruction following the arithmetic operation. If the program just wants to branch on the result of overflow, LLVM performs it using a JO or JNO instruction. Overflow checks that crash the program (e.g., in debug builds) are implemented as an ordinary branch that calls into the panic handler.
Do you suggest we should carry on bad design decisions made in the past? x86 is an exhibition of bad choices and I don't think we need to copy them.
> and is seldom used
I believe it is not like this. I think that in most cases you need non-wrapping addition, for example, if you are calculating totals for a customer's order, counting number of visits for a website, or calculating loads in a concrete beam.
Actually wrapping addition is the one that is seldomly used, in niche areas like cryptography. So it surprises me that the kind of addition that is used more often (non-wrapping) requires more instructions than exotic wrapping addition. What were CPU designers thinking I fail to understand.
If you do wrapped addition without flags, you have one self-contained instruction that even covers signed and unsigned integers. If you want other behaviour, you then have to specialize for signed or unsigned, specialize for the choice of wrap/trap/flag, and make those traps and flags work nicely with whatever other traps or flags you might have.
So, yeah, if you want the simplest possible thing, driven by some decision other than the best outcomes for software in general, then you would choose wrapping addition without flags or traps.
If you want to have checked arithmetic, RISC-V's openness allows you to make a custom extension, implement hardware for it (FPGA is cheap and easy), implement software support and demonstrate the claimed benefits, and encourage others to also implement your extension, or standardise it.
It is simply not possible to do this in the x86 or Arm worlds. And that is one of the problems RISC-V solves -- a meta problem, not some one individual pet problem, but potentially all of them.
Any code size increases are made up for elsewhere and they STILL get smaller code too.
Furthermore, it achieves all of that with a much simpler ISA that matches x86 and arm in features, while having an order of magnitude less instructions to implement and verify.
RISC-V wasn't around when this paper was written, but it's close enough to MIPS to disprove the claim that "RISC-V code is significantly smaller": https://web.eece.maine.edu/~vweaver/papers/iccd09/iccd09_den...
>Compiler output does not matter
>1987 paper
>RISC-V encoding "close enough to MIPS"
>disprove the claim that "RISC-V code is significantly smaller"
F for effort.
Did you even look at the link?
Neither shilling nor trolling is welcome here. Is there a relationship you haven't disclosed with RISC-V?
Yes, I did.
>RISC-V encoding "close enough to MIPS"
... while pointing at MIPS-X, 1987. Deranged.
>Is there a relationship you haven't disclosed with RISC-V?
Are you projecting? I have noticed a pattern in your appearances whenever a discussion about RISC-V pops up.
Anyways, this game is going to really end up won by people higher in the stack paying the price for bounds checks and including them no matter what, because not having them is not tenable for their usecase. This drives processor manufacturers to make these checks more efficient which they have been doing for many years.
"Faulting" addition should be as fast as wrapping addition and take a single instruction. Yes, I want hardware-accelerated overflow checking because it leads to more accurate results and prevents security vulnerabilities.
By the way, I want FPU operations to cause traps too (when getting infinity or NaN).
Then add multiple overflow checking units.
> one of them has a throughput of 4/cycle and the other one will be 3/cycle and compiler authors will pick the former every time.
Currently on RISC-V checked addition requires 4 dependent instructions, so its throughput is about 1 addition/cycle.
You can't.
With your favoured ISA style you can't just put 4 or 8 checked overflow add instructions in a row and run them all in parallel because they all write to the same condition code flag. You have to put conditional branches between them.
Or, if you want an overflowing add to trap then you can't do anything critical in the following instructions until you know whether the first one traps or not e.g. if the instructions are like "add r1,(r0)+; add r2,(r0)+; add r3,(r0)+; add r4,(r0)+". In this example you can't write back the updated r0 value until you know whether the instruction traps of not. Even worse if you reverse the operands and have a RMW instruction.
This can be implemented using traps, without flags. And RISC-V supports delayed exceptions, which makes the implementation easier.
> In this example you can't write back the updated r0 value until you know whether the instruction traps of not.
RISC-V supports delayed exceptions, so you actually can.
>It has a soup of wacky opcodes to optimize corner cases
OK, go ahead and name one (1) such opcode. I'll wait.
>obscure vendor specific extensions that are absolutely CISC-y (examine T-Head's additions if you don't believe me!).
Yes, these extensions are harmful, and that's why they're obscure and vendor-specific.
RISC-V considers pros and cons, evaluates across use cases, and weights everything when considering whether to accept something into the standard specs.
Simplicity itself is valuable; that is at the core of RISC. So the default is to reject. A strong argument needs to be made to justify adding anything.
You don't get a choice in the matter.
> can be easily replaced with two separate instructions
It can't. You will get different answers.
RISC-V allows you to choose a CPU without floating point instructions. But if you choose to have an FPU then you get multipy-add. Yes, it needs to read three registers, which is expensive. It is also the most common instruction in any floating point calculation, so that expensive three port register file gets used constantly.
Checking overflow for addition on the other hand is something that is very seldom used (on any CPU). On RISC-V you need four instructions only if the operands are full register size and you don't know anything about either operand. If you know the sign of one operand then the cost reduces to one extra instruction.
I think a lot of that is due to the popularity of C, and the fact that C has no built-in support for overflow checking. In some alternate timeline in which C had that feature (or a different language which had that feature took C's place), I suspect it would have been used a fair bit more often.
Well C23 finally adds checked arithmetic, in <stdckdint.h>. But, it took until 2023 to do it, what if it had been there 20, 30, 40 years ago? Very little software supports it yet anyway.
And it isn't using the same syntax as standard arithmetic. Instead of `c = a + b`, you have to do `ckd_add(&c, a, b)`. That isn't going to encourage people to use it.
I believe you are wrong. Almost every addition used in software should be a proper addition, not addition module 2^32 or 2^64. For example, if you want to calculate total for customer's order, you want proper addition, not a remainder after division by 2^32. Or if you are calculating a number of visitors of a website, again, you need the correct number.
Addition modulo N is used only in niche cases like cryptography.
In my opinion, it is wrapping addition which is seldomly used. I can't remember last time when I needed it. So it is surprising that RISC-V makes rarely used operation take less instructions than more popular one.
You might argue, that some poorly designed ancient languages have '+' operator to perform wrapping addition, however that is only because they are poorly designed, not because users want such method of addition. For comparison, a properly designed language, Swift has non-wrapping addition.
... and niche cases like GIS location computations on a spherical planet and any form of engineering | physics mesh computation.
It's inescapable when you peer into the guts of any earth based modelling from satellte data .. something that happens on a daily terrabyte scale.
> Addition modulo N is used only in niche cases ...
and not modulo 2^N.
The point that I would make is that general purpose CPU's doing general everday tasks such as https connections, secure transfers, GIS mapping, etc are doing a great many more modulo operations than acknowledged above.
I certainly hope for at least some of that code the compiler ends up making use of adc and family, otherwise it's gonna be utterly miserable. It's great that the language is hiding that complexity from the programmer, but it's a big mistake to imply that this means it does not happen at all.
Javascript stores its "integers" in the mantissa of a floating point NaN and makes no attempt whatsoever to hide the implications of that decision from the unsuspecting developer; and good grief that leads to an incredible amount of pain and suffering.
Arithmetic on numbers larger than your word size. Poster child: crypto. It's 2023 and crypto is not rare. This post cannot get from me to you without crypto in the datapath.
I have several theories:
1. x86 refused to die as expected, so the RISC vs CISC debate doesn't have a clear winner. There are reasonable arguments that RISC won, CISC won, or it no longer matters.
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 "personal identity" more than most topics. The debate also has an underdog vs entrenched monopoly vibe that makes it more interesting.
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's vague enough that nobody can agree on anything.
4. RISC exists on three levels: First, a design philosophy / 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's lots of room for debate.
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.
(I've been trying to make a blog post on this subject, but it keeps spiraling off in random directions.)
I agree with the philosophy and ISA, but I don't think RISC is actually counts as a hardware architecture.
Yes, there is a certain style of architecture strongly associated with RISC, the "classic RISC pipeline" that a lot of early RISC implementations share. But RISC can't claim ownership over the concept of a pipelined CPUs in general and designers following the RISC philosophy almost immediately branched out into other hardware architectures directions like superscalar and out-of-order execution (some also branched into VLIW).
Today, the "class RISC pipeline" is almost entirely abandoned outside of very low-power and low-gate count embedded cores.
The primary advantage of the RISC philosophy was that it allowed them to experiment with new hardware architecture ideas several years early than those competitors who were stuck supporting legacy CISC instruction sets. Especially when they could just dump their previous ISA and create a new one hyper-specialised for that exact hardware architecture.
Those CISC designers also followed the same path in the 80s and 90s, implementing pipelined architectures, and then superscalar and then out-of-order, but their designs always had to dedicate more gates to adapting their legacy ISAs to an appropriate internal representation.
----
But eventually silicon processes got dense enough for this inherent advantage of the RISC philosophy to fade away. The overhead of supporting those legacy CISC ISAs got smaller and smaller.
All high-performance CPUs these days seem to have settled on a common hardware architecture, doesn't matter if they use CISC or RISC ISAs, the diagrams all seem to look more or less the same. This architecture doesn't really have a name (which might be part of the reason why everyone is stuck arguing RISC vs CISC), but it's the out-of-order beast with absolutely massive reorder buffers, wide-decoders, physical register files, long-pipelines, good branch predictors, lots of execution units and (often) an uOP cache.
Intel's Sandybridge is the first example of this exact hardware architecture (though that design linage starts all the way back with the Pentium pro, and you also have AMD examples that get close), but Apple quickly follows up with Cyclone and then AMD with Zen. Finally ARM starts rapidly catching up from about the Cortex A76 onwards.
(And to be fair to those marketers, for a time the microarchitectural improvements that the RISC movement wrought really were enormous.)
https://en.wikipedia.org/wiki/NexGen
Here's an old BYTE article from 1994:
The 29K was a really cool architecture and I’m sorry it didn’t make it. AMD’s pathetic marketing of the time couldn’t even beat MIPS’ terrible marketing, plus MIPS had SGI (and later SGI had MIPS).
(1) RISC really is the fastest/best way for CPUs to operate internally.
(2) x86 performance isn't held back (much) by its outmoded instruction set.
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.
They could if they want to (because they have) but they don't want to anymore. Presumably because it's not the best way to do it. Although I guess it could be slightly better but not worth the cost of translating.
"x86 instructions decompose into operations that feel somewhat RISC-like"
And this is pretty much true.
The author of this piece somewhat fixates on RISC-V as the anointed version of "RISC-ness" when it really is just one expression of the idea. The whole RISC vs CISC distinction is pretty silly anyway, because there isn't really a clear criterion or dividing line (see ARM's "RISC" instruction set) that separates "RISC" from "CISC." They're basically just marketing terms for "my instructions are reasonably simple" (RISC) and "my instructions are reasonably expressive" (CISC).
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.
I recall seeing them in Polish computer mags with G3 iMac 333 MHz or so.
68040 was faster than original 486, 486dx2 took a lead.
PPC601 was faster than original Pentium. No question. P55C pulled ahead.
PPC G3 immediately leaped past PII. I remember in mid 1998 my employer provided me with a PII 400 and my 266 MHz G3 Powerbook smoked it.
Coppermine P3 was indeed a great advance. And then G4 got going, and by the time chips reached 1.25 and 1.42 GHz the G4 had pulled ahead.
During that G4 (and G5) period many Macs were dual-processor, or even quad for the G5, giving an overall performance advantage even if single-threaded performance was sometimes a little slower. Intel PCs (rather than servers) seldom had dual processor until the Core 2 Duo -- which Apple adopted even before most PC manufacturers.
> To make it seem like the whole PowerPC thing had been a good idea you had to cherry-pick the best Mac and an old PC as a baseline.
No. You just had to pick the right point in time. Sometimes one was faster, sometimes the other.
In point of fact beyond the instruction decode stage all modern cores look more or less identical.
I don't see how that follows at all? MIPS in fact is about as pure a "RISC" implementation as is possible to conceive[1], and it shares all its core ideas with RISC-V. You absolutely could make a deeply pipelined superscalar multi-core MIPS chip. SPARC has the hardware stack engine to worry about, but then modern CPUs have all moved to behind-the-scenes stack virtualization anyway.
No, CPUs are CPUs. Instruction set architectures are a vanishingly tiny subset of the design of these things. They just don't matter. They only seem to matter to programmers like us, because it's the only part we see.
[1] Branch delay slots and integer multiply instruction notwithstanding I guess.
And, yes, they learned the hard way that register windows are a bad idea. Patterson says they did it because their compiler didn't have as good register allocation as Stanford's compiler.
Am I correct in recalling they removed branch delay slots in a later iteration of the chips?
Had to write MIPS assembly by hand recently, incredibly counter intuitive.
An internal fixed with encoding inside the instruction cache may work.
Uh, why? Instructions start at byte boundaries. Say you want to decode an whole 64 byte cache line at once (probably 10-14 instructions on average). Thats... 64 parallel decode units. Seems extremely doable to me, given that "instruction decode" isn't even visible as a block on the enormous die shots anyway.
Obviously there's some cost there in terms of pipeline depth, but then again Sandy Bridge showed how to do caching at the uOp level to avoid that. Again, totally doable and a long-solved problem. The real reason that Intel doesn't do 10-wide decode is that it doesn't have 10 execution units to fill (itself because typical compiler-generated code can't exploit that kind of parallelism anyway).
Overlaid on a higher resolution die shot https://static.wixstatic.com/media/5017e5_982e0e47d7c04dd693...
Here's a POWER8 floorplan: https://cdn.wccftech.com/wp-content/uploads/2013/08/IBM-Powe... (The decoder is subsumed under IFU)
And POWER9 https://www.nextplatform.com/wp-content/uploads/2016/08/ibm-...
Didn't find any recent, reliable sources for Intel cores.
I wonder how wide SIMD has to get before you treat it like a CPU embedded into cache memory.
Though I guess we are already looking at SIMD instructions wider than a cache line…
The divergence was one of philosophy, and had unexpected implications.
CISC was a “business as usual” evolution of the 1960s view (exception: Seymour Cray) that you should make it easy to write assembly code so have lots of addressing modes and subroutines (string ops, BCD, etc) in the instruction set.
RISC was realizing that software was good enough that compilers could do the heavy lifting and without all that junk hardware designers could spend their transistor budget more usefully.
That’s all well and good (I was convinced at the time, anyway) but the results have been amusing. For example some RISC experiments turn out to have painted their designs into dead ends (delay slots, visible register windows, etc) while the looseness of the CISC approach allowed more optimization to be done in the micromachine. I did not see that coming!
Agree on the point that the cores themselves have found a common local maximum.
In the 70s, everyone designing an ISA was doing CISC. Then in the 80s, everyone suddenly switched to designing RISC ISAs, more or less overnight. There weren't any holdouts, nobody ever designed a new CISC ISA again.
The only reason why it might seem like there was a divergence is because some CPU microarchitecture designers were allowed to design new ISAs to meet their needs, while others were stuck having to design new microarchitecture for legacy CISC ISAs which were too entrenched to replace.
> For example some RISC experiments turn out to have painted their designs into dead ends
Which is kind of obvious in hindsight. The RISC philosophy somewhat encouraged exposing pipeline implementation details to the ISA, which is a great idea if you can design a fresh new ISA for each new CPU microarchitecture.
But those RISC ISAs became entrenched, and CPU microarchitecture found themselves having to design for what are now legacy RISC ISAs and work around implementation details that don't make sense anymore.
Really the divergence was fresh ISAs vs legacy ISAs.
> while the looseness of the CISC approach allowed more optimisation to be done in the micromachine.
I don't think this is actually an inherent advantage of CISC. It's simply result of the shear amount of R&D that AMD, Intel, and others poured into the problem of making fast microarchitectures for x86 CPUs.
If you threw the same amount of resources at any other legacy RISC ISA, you would probably get the same result.
>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.
Especially with its 143 bit long instructions and memory-memory operands.
Now, K5 was a different beast, with it's "microcode" being a frontend that converted x86 to AMD29k
(I've used both of those two examples, but it's been a while, and I don't have any particular desire to crack open their architecture manuals to see how CISCy or RISCy they are. It's kind of an academic distinction anyway at this point.)
Recent ESP32 processors have a "ULP Coprocessor" for ultra-low-power operations. Its instruction set is... well... not very RISCy: https://docs.espressif.com/projects/esp-idf/en/v4.2/esp32/ap...
(Spoiler alert for the lazy: it has single instructions for ADC reads and I2C transactions and such. I don't think it gets more CISC than that!)
That makes it quite RISCy. The overpowered instructions are just because it's an IO processor, they don't do much work on the CPU core itself, just trigger an IO component.
23 + max(1, SAR_AMP_WAIT1) + max(1, SAR_AMP_WAIT2) + max(1, SAR_AMP_WAIT3) + SARx_SAMPLE_CYCLE + SARx_SAMPLE_BIT cycles to execute
4 cycles to fetch next instruction
But this whole discussion is and has always been rather fuzzy, so it's something of a moot point.
It's not just that the RISC philosophy became popular, but suddenly it didn't make much sense to design a CISC ISA anymore.
CISC was a great idea when you had really slow and narrow RAM. It made sense to try and make each instruction as short and powerful as possible, usually using microcoded routines. But RAM got cheaper, buses got wider and caches started being a thing. It didn't make any sense to waste transistors on microcode, just put them all in RAM.
The appeal of CISC instruction sets when marketing to programmers lies in their batteries-included stance: they handle more of the binary encoding stuff for you, more of the math operations. With a RISC approach they have to write library code to do the same tasks, which adds some implementation complexity as well as potentially being most of the size of a short program. And that makes sense - if you expect direct instruction encoding to be the whole programming environment, which, for the first computers, it had to be.
By the time you get to the microcomputer era the balance had shifted pretty resoundingly towards working at a higher level - that's why nearly every machine of that generation had a BASIC, and if you have a BASIC it's more important for the instruction set to be efficient, because efficiency becomes the only reason to drop down from a high level environment.
With RVA22, RISC-V has already caught up with ARM and x86 functionality.
Yet, It does not have their complexity. It is not even close.
https://www.renesas.com/us/en/products/microcontrollers-micr...
There is also MSP430, a 16 bit microcontroller that is pretty much a PDP-11 with the register set increased from 8 to 16 (4 bit field instead of 3) by reducing the number of addressing modes from 8 (3 bit field for each operand) to 4 for the src operand and 2 for the dst operand. This also gives 1 extra bit for the opcode field.
Incidentally, the M68000 is itself pretty much a 32 bit PDP-11 with the register set increased from 8 to 16 by differentiating D and A registers and reducing most instructions (except MOV) to have 8 addressing modes for only one operand, with the other operand always being a register.
AS/400 is another interesting one. It was introduced on a System/38 base but intended for future transition to POWER.
When the AS/400 was released in 1988, they weren't thinking about POWER at all. The point of AS/400 was to unify their existing S/36 and S/38 midrange lines; the AS/400 was essentially a new version of the S/38 with added S/36 compatibility features. Its "technology independence" had been a feature of the S/38 since its initial release in 1978; S/38 in turn had inherited the idea from IBM's 1971–1975 "Future Systems" project, a failed attempt to build a successor to the 360/370 mainframe line. RISC wasn't the original motivation for the idea since the term hadn't even been coined when it was first developed.
In 1990, they began a project to develop a successor to the CISC IMPI CPU. They briefly evaluated POWER, but rejected it as unsuitable for their needs – so they started designing their own custom CPU architecture, "Commercial RISC" or "C-RISC" for short. Despite its name, it wasn't a true RISC architecture – it actually kept the CISC IMPI instruction set for backward compatibility, but added new simpler RISC-style instructions alongside it. I think the idea was new compilers would generate the new RISC instructions which would be hardwired, whereas the legacy CISC instructions would be microcoded.
By mid-1991, IBM HQ came to realise they had two different divisions working on "RISC" projects (PowerPC in Austin and C-RISC in Minnesota), and did not approve of the duplication – they ordered C-RISC killed, and the AS/400 was instead to use POWER/PowerPC, with the addition of any necessary extensions. However, while that decision was arguably best for the long-term, it did delay the project by at least a year, since the jump from IMPI to POWER was much bigger than from IMPI to C-RISC. The MI bytecode was only used by applications and the highest levels of the OS; huge parts of the OS were compiled directly to IMPI, and IMPI, while lower-level than MI, still had some rather high-level features which POWER lacks, such as hardware multitasking, and knowledge of the basic structure of the 128-bit capability/single-level-store addresses.
Source: Frank Soltis, Inside the AS/400, 1996
fsck, that hurts.
The jump from 32 bit to 64 was not so dramatic. I Wonder if I’ll be around for 128 bit. I suspect the big disruption there will be changing the CPU cache line size, which has been stuck at 64 bytes for ages. I can’t imagine 4 words per cache line will be efficient.
ARM1 is what it is. They didn't have the time to do it properly, or the hindsight we have now.
They had to get their product out.
But we know better, now.
https://news.ycombinator.com/item?id=27334855
https://www.google.com/search?q=%22christopher+domas%22+x86+...
https://en.wikipedia.org/wiki/Alternate_Instruction_Set
>"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 "deeply embedded core" (DEC) plus "deeply embedded instruction set" (DEIS) for the RISC instruction set, "launch instruction" for JMPAI, "bridge instruction" for the x86 prefix wrapper, "global configuration register" for the Feature Control Register (FCR), and documented the privilege escalation with the name "Rosenbridge".[5]"
Also -- I should point out that the debate of if x86 (CISC) CPU's contain RISC cores -- is largely academic.
Both RISC and CISC CPU's contain ALU's -- so our only debate, really, if we have one, is how exactly data that the ALU is going to process -- is going to wind up at the ALU...
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...
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.
x86 microcode update blobs -- are binary "black boxes" and encrypted.
Most of our (limited) knowledge in this area comes from various others who have attempted to understand the internal workings of x86 microcode:
https://www.google.com/search?q=%22reverse+engineering+x86+p...
https://github.com/RUB-SysSec/Microcode
https://twitter.com/_markel___/status/1262697756805795841
https://www.youtube.com/watch?v=lY5kucyhKFc
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...
To (mis)quote Douglas Adams:
"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."
There is another theory which states that this has already happened." :-) <g>
Some older CPUs were truly "microcoded." The heart of the CPU was an interpreter loop which took instructions, then invoked a ROM / microcode routine corresponding to the implementation for that instruction. Each instruction began with the runtime selecting an instruction and ended with the microcode routine returning to a loop. A good example of this is the 8086: http://www.righto.com/2022/11/how-8086-processors-microcode-... . These CPUs worked like a traditional "emulator."
That is NOT how a modern x86 CPU works. A modern CPU works a lot more like a JIT. In a modern x86 CPU, "microcode" runs _alongside_ the main CPU core execution. The microcode runtime can be thought of as a co-processor of sorts: some complex instructions or instructions with errata are redirected into the microcode co-processor, and it's responsible for breaking those instructions down and emitting their lower-level uOps back into the execution scheduler. However, most instructions never touch microcode at all: they are decoded purely in hardware and issued into the scheduler directly.
This is important because when people start talking about the x86 "microcode layer," they quickly get confused between the "microcode" (which is running _alongside_ the processor) and uOps, which are the lower level instructions issued into the processor's execution scheduler.
uOps and how they function should be included in any serious study of x86 hardware.
In an ideal world, they would be well documented by vendors.
(Random Idea: I wonder if it is possible to use some feature of some newer x86 chip to issue an x86 instruction -- and then to have it retrieve the uOp structure for that instruction as data... sort of like a uOp proxy or debug facility... If newer x86 chips don't have that function -- then a future x86 chip (which doesn't necessarily have to be be Intel) should...)
>In a modern x86 CPU, "microcode" runs _alongside_ the main CPU core execution.
Indeed!
The broader picture of a CPU, any CPU, is that there's a lot that is happening at the same time. A lot of signals (and data!) moving around, and changing around for various purposes! (In other words, modern CPU's don't work linearly, like a computer program -- unless perhaps we talk about the earliest oldest CPU's...)
But the study of uOps should be undertaken in any serious study of the x86...
It should be pointed out that the number of uOps -- should be less, way less, than the number of x86 instructions, since each x86 instruction is implemented in one to several uOps, and these uOps frequently repeat across instructions...
Which again brings us the academic question of "if there are way fewer uOps than x86 instructions -- then can the set of uOps if taken by themselves be considered a RISC?" Why or why not?
Which brings us to Christopher Domas' discovery that some VIA x86 Samuel 2 processors had an "Alternate Instruction Set" -- what is the Alternate Instruction Set's relation to uOps? Is the AIS direct uOps, or 1:1 mapping? Or was it implemented by microcode that translated each AIS instruction into multiple uOps, and if so, how was that microcode implemented?
As an addendum, I found the following resource for uops online:
Anyway, some excellent points in your post!
Domas found it independently by fuzzing. However, the publically available documentation of the time (16 years prior to Dumas's work) did say how to switch to AIS mode, the basic format of the AIS instructions (the needed prefix and that they're 32bit) and how to prevent access to AIS mode was actually well documented. Indeed, support for the "new branch instruction" was actually added to NASM back in 2002.
This documentation also states that it is available on all VIA C3 processors (so also stuff like Eden). There are also hints that it was available earlier (eg., the documentation references an instruction being available on the "C2", which I assume is one of the IDT Winchip designs), and I've see rumours of something on the VIA Nano processors.
So, a little reading would have saved Dumas quite a lot of time; although it's certainly a good demonstration of how one can go about finding similar features.
What wasn't easy to find at the time was the actual AIS instruction set, this has now been uploaded to bitsavers, although it's a somewhat early and incomplete version.
> what is the Alternate Instruction Set's relation to uOps? Is the AIS direct uOps, or 1:1 mapping? Or was it implemented by microcode that translated each AIS instruction into multiple uOps, and if so, how was that microcode implemented?
The introduction of the now available application note, states that these are the micro-operations, albeit not the entire set: "the VIA C3 processor has a special operation mode where the front end logic can also fetch (selected) micro-operations (versus x86 instructions) and pass them directly to the internal execution unit."
The (now available) Alternate Instruction Set Programming Reference states "the VIA C3 processor comprises two major components: a front-end that fetches x86 instruction bytes, and an internal microprocessor that executes these internal instructions."
In particular it seems to be a MIPS core with extensions/modifications optimised for emulating an x86 processor - there are instructions with "special control fields to allow most ALU semantics to be specified in a single 32bit instruction" and instructions that are "needed to perform a single-cycle X86 [instruction name] function".
Why MIPS? Because the Programming Reference says "There are no MIPS format load/store instructions and no way to perform load/stores to native-mode address space. All load/store operations use X86 address and load/store semantics". Without pulling up a MIPS instruction set, and comparing, it also looks a lot like MIPS (32 registers, constant 0 register etc.,)
Notably, you can even interleave x86 instructions and these uOP instructions (with some restrictions), I doubt the internal core is microcoded, the references to "single-cycle" and "MIPS" would seem to preclude that.
However, there may not be access to all the possible uOPs (the appnote says "selected" plus there are multiple references to a "translator", and registers used for "Xlator-ucode communication"). Of course, this translator could be hardware that, say, deals with all x86 instructions that map to a single uOP, perhaps skipping the MIPS decode. Thus the translation directly feeds the RISC core with single translated instructions where there is a mapping or with a ucode instruction stream from a ROM where the implementation requires multiple instructions. This format would make the wrapper instructions very easy to implement.
If you're interested, there's a wikipedia page - https://en.wikipedia.org/wiki/Alternate_Instruction_Set - with links to the documentation.
The simplest horizontally microcoded CPUs had their "decoder" be essentially mapping into microcode ROM, where said microcode contained instructions that directly drove various components of the CPU, coupled with some flags regarding next micro-instruction to execute.
Many instructions could in fact decode to single "wide" instruction, with sequencer-controlling bits telling it to load the next instruction and dispatch it. Others would jump to microcode "dispatch" routine which usually was uOP(s) that executed advancing of program counter and triggering load of next instruction to appropriate register then jumped based on that.
Usually multiple wide instructions per macroinstruction happened either for complex designs (there were microcoded CPUs whose microcode was multitasking with priority levels!) or when decoded instruction mapped into a more complex sequence of operations (take for example a difference between an "ADD" between two registers and an "ADD" that does complex offset calculation for all operands - or PDP-10 style indirect addressing, where you'd loop memory load until hitting the final, non-indirect address).
To make it simpler, it was common to make microcode ROMs have multiple empty slots between addresses generated by sequencer, so that you avoided jumps unless you got really hairy instruction (largest possible VAX instruction was longer than its page size).
This was around the time IBM was pushing Power and everyone thought it was poised to dominate the industry.
https://www.zdnet.com/article/transmetas-crusoe-how-it-works...
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/Firestorm core where Apple could easily fit 8 ARM 64 bit ISA Instruction Decoders on the A14/Later Performance core designs! So the A14/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.
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/Earlier and Intel Being 6 wide with Golden Cove that's got only One complex x86 decoder and 5 "Simple" x86 decoders on that design that the tech press has never deep dived the difference there Complex/Simple in that Golden Cove Instruction Decoder design.
But the x86 cores are usually clocked around 2GHz higher than Apple's A14/Later cores in Apple'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/Later Apple cores that are extra wide and high IPC in design that can be clocked well inside their Performance/Watt sweet spot range on laptops and have the best battery life metrics on the consumer market. And that's compared to the x86 cores that have to be clocked higher there and outside their Performance/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.
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'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/Watt sweet spots unlike the narrow x86 cores that have to get clocked well outside their Performance/Watt sweet spots to achieve a similar single core performance than the extra wide order superscalar A14/Later Apple designs.
And Apple's A14/Later core designs can be used in Smartphones/Tablets and Laptop/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/Watt sweet spots there on whatever process node utilized!
IMHO the RISC vs CISC debate was never about implementation, only ISA. Even the 8086 uses a combination of microcoded and non-microcoded instructions (https://news.ycombinator.com/item?id=35939168).
Also, calling it a "legend" in the title is rather clickbaity.
One part of it was certainly about quantitatively adding instructions that could be used (by the programmer / compiler), but that was inextricably linked to the other side of the coin which is to define instructions that could be implemented in a performant way. Instruction complexity, addressing modes, lack of load-op, etc were all based on simplicity and high frequency pipelining. To a fault in some cases, famously branch delay slots in Stanford's architecture, a choice only explainable as a decision to complicate the ISA in order to make (contemporary) implementations simpler. Others as well though -- it's not that compilers were incapable of using or benefiting from load-op instructions for example. It's just that they were harder to implement.