In our computer systems lecture we were introduced to the MIPS processor. It was (re)developed over the course of the term and has in fact been quite easy to understand. It uses a RISC design, that is its elementary commands are regularly encoded and there are only few of them in order to keep the wires simple.

It was mentioned that CISC follows a different philosophy. I looked briefly at the x86 instruction set and was shocked. I can not image how anyone would want to build a processor that uses so complex a command set!

So I figure there have to be good arguments why large portions of the processor market use CISC architectures. What are they?


11 Answers 11


There is a general historical trend.

In the olden days, memories were small, and so programs were perforce small. Also, compilers were not very smart, and many programs were written in assembler, so it was considered a good thing to be able to write a program using few instructions. Instruction pipelines were simple, and processors grabbed one instruction at a time to execute it. The machinery inside the processor was quite complex anyway; decoding instructions was not felt to be much of a burden.

In the 1970s, CPU and compiler designers realized that having such complex instructions was not so helpful after all. It was difficult to design processors in which those instructions were really efficient, and it was difficult to design compilers that really took advantage of these instructions. Chip area and compiler complexity was better spent on more generic pursuits such as more general-purpose registers. The Wikipedia article on RISC explains this in more detail.

MIPS is the ultimate RISC architecture, which is why it's taught so often.

The x86 family is a bit different. It was originally a CISC architecture meant for systems with very small memory (no room for large instructions), and has undergone many successive versions. Today's x86 instruction set is not only complicated because it's CISC, but because it's really a 8088 with a 80386 with a Pentium possibly with an x86_64 processor.

In today's world, RISC and CISC are no longer the black-and-white distinction they might have been once. Most CPU architectures have evolved to different shades of grey.

On the RISC side, some modern MIPS variants have added multiplication and division instructions, with a non-uniform encoding. ARM processors have become more complex: many of them have a 16-bit instruction set called Thumb in addition to the “original” 32-bit instructions, not to mention Jazelle to execute JVM instructions on the CPU. Modern ARM processors also have SIMD instructions for multimedia applications: some complex instructions do pay after all.

On the CISC side, all recent processors are to some extent RISC inside. They have microcode to define all these complex macro instructions. The sheer complexity of the processor makes the design of each model take several years, even with a RISC design, what with the large number of components, with pipelining and predictive execution and whatnot.

So why do the fastest processors remain CISC outside? Part of it, in the case of the x86 (32-bit and 64-bit) family, is historical compatibility. But that's not the whole of it. In the early 2000s, Intel tried pushing the Itanium architecture. Itanium is an extreme case of complex instructions (not really CISC, though: its design has been dubbed EPIC). It even does away with the old-fashioned idea of executing instructions in sequence: all instructions are executed in parallel until the next barrier. One of the reasons Itanium didn't take is that nobody, whether at Intel or elsewhere, could write a decent compiler for it. Now a good old mostly-sequential processor like x86_64, that's something we understand.

  • 4
    $\begingroup$ One of the reasons is that CISC came out of limited memories (making compact instructions a must), today's CPUs are much faster than the memory (one memory fetch takes enough time to execute hundreds of instructions, and the gap is getting wider), so compact instructions are at a premium in order to use cache effectively. $\endgroup$ – vonbrand Feb 1 '13 at 12:24
  • $\begingroup$ Oh, and one of the driving forces behind RISC were analysis of instructions executed on the day's CISC machines. They turned out overwhelmingly simple instructions, so the extra effort (circuit- and timewise) of decoding complex instructions was mostly wasted. $\endgroup$ – vonbrand Feb 1 '13 at 12:26
  • 2
    $\begingroup$ @vonbrand: On processors that include instructions like dec [address], they tend to be used quite a bit and offer a significant advantage over ldr r0,[address] / sub r0,#1 / str r0,[address] on architectures that can implement them efficiently. The emergence of RISC stems from the fact that while a non-pipelined machine might implement a dec more than twice as fast as a load/sub/store sequence, pipelining can improve the speed of the latter sequence more than it can improve the speed of the read-modify-write instruction. $\endgroup$ – supercat Feb 8 '15 at 19:58
  • $\begingroup$ @vonbrand is right, in that RAM isn't nearly as precious as it was, but cache is. Huffman coding the instruction set (which is kind of what CISC is these days) is still valuable in that sense. $\endgroup$ – Pseudonym Jul 22 '15 at 0:19
  • $\begingroup$ Well, that's something I never knew about Itanium! Thanks. (also, wish someone still made the higher-end MIPS CPUs - they sound like they'd be fascinating to program for. I know the designs exist but no one's made them off of FPGAs -_-) $\endgroup$ – Wyatt Ward Jul 28 '16 at 22:58

The x86 instruction set is a bit of a special case. I think that Motorola's 68K and DEC's VAX are somewhat better examples of CISC. In the days of a lot of assembly-language code, people thought that a very regular, very inclusive ISA was better: I believe they called the difference between assembly code and the way people thought the "Semantic Gap". Theoretically, you wanted an instruction set that matched the way you thought.

The other big design driver for CISC seems to be "orthogonality": every instruction would work with every addressing mode (register, absolute address, relative offset, etc etc). You can see the bogey man of orthogonality show up in API design in Distributed Computing Environment (DCE) and in CORBA. That idea isn't limited to instruction set design.

  • 5
    $\begingroup$ Funny how orthogonality in practice turns out to mean the union of all options. $\endgroup$ – Dave Clarke Apr 2 '12 at 19:51
  • $\begingroup$ That ortogonality certainly can be taken too far, but it is a useful helper to the memory. I loved the Motorola 6502, but it had all sorts of infuriating "this instruction takes X, that similar one only Y, the third one none at all" restrictions on register usage. Meeting the VAX was liberating... $\endgroup$ – vonbrand Mar 19 '13 at 20:56
  • $\begingroup$ @vonbrand: The 6502 wasn't Motorola--it was MOS Technologies, which produced it as a competitor to the Motorola 6800. I've sometimes wondered whether the 6502 would have been simpler or more complicated if all the non-branch instructions which took operands used the same encoding (24 instructions times eight addressing modes could be decoded quite easily). I find it particularly curious that CMP works with eight addressing modes, and DEC with only four, but (on NMOS versions of the 6502) if one "OR"s together the opcodes for those instructions, not only will one get a "DCP" instruction... $\endgroup$ – supercat Dec 11 '13 at 0:13
  • $\begingroup$ ...which behaves like DEC, but then compares the result of the decrement with the value in the accumulator and sets flags appropriately, but DCP will correctly handle addressing modes which are unavailable with DEC. Weird that the hardware can correctly handle (ZP),Y addressing with a read-modify write instruction, but the instruction decoder won't let that mode work in any documented read-modify-write instructions. $\endgroup$ – supercat Dec 11 '13 at 0:17
  • 1
    $\begingroup$ From what I read, the "R" in RISC doesn't mean the processor has a reduced set of instructions, but rather that it has a set of reduced instructions; the biggest aspect of that is the requirement that memory loads and stores not be combined with other operations. $\endgroup$ – supercat Dec 11 '13 at 0:18

One reason for CISC was to have dense encoding for instructions (memory was expensive). The whole RISC idea was to speed up the CPU by fetching the same size instructions all the time (no complex, slow "figure out instruction size" step), have them do simple things (so it is fast to figure out what to do). Memory was cheap. This freed circuitry area on the CPU for other stuff (more registers, more processing units so several instructions could be done in parallel if they were independent). As the CPU was much slower than RAM, this paid off. But CPUs got faster (and did more in parallel, and ...) while RAM didn't get faster (at least not at the same rate than the CPU's consumption of data due to increased parallelism). Meet cache memory, fast as the CPU but small. So now memory is at a premium again, not for cost reasons but for speed. CISC revival time. Meanwhile, CPUs got more complex, to the point that today's microprocessor does much of what a RISC compiler did: Break down operations into elementary parts, reorder internal RISCy instructions so they can be done concurrently whenever possible. RISC was badmouthed as "Relieve Important Stuff to Compiler" for a reason...

  • 3
    $\begingroup$ Memory capacity is still important in some embedded systems, particularly microcontrollers where all memory/storage is on the processor chip. This was probably a significant factor for Renesas' introduction of a new CISC ISA--RX--, i.e., not just code density for performance but (mainly?) for reduced storage. $\endgroup$ – Paul A. Clayton Mar 20 '13 at 0:29
  • $\begingroup$ From what I understand, the "R" of RISC referred not to the set of instructions being reduced, but rather to the instructions themselves being reduced. Most notably, in a CISC processor like the 8086, one can add a value directly to memory, but in a RISC the load, add, and store must be performed as separate steps. In many cases, CISC machines have variable-length instruction sets and denser instruction codings than RISC machines, but newer ARM processors use variable-length instructions and yet still separate loads and stores. $\endgroup$ – supercat Dec 11 '13 at 0:22
  • $\begingroup$ @PaulA.Clayton This is correct but I'm going to be pedantic and point out that you can interface external RAM (either SRAM or DDR through a controller) and expand your memory capacity at the cost of added complexity and reduced practicality. $\endgroup$ – Wyatt Ward Jul 28 '16 at 23:03

The real advantage of CISC is reduced memory and cache pressure and that alone makes it better for demanding high performance applications since a major bottleneck in such systems is the memory bandwidth. Given equally sized cache memory, CISC processors can describe more information than RISC. Also, since CISC instructions involve several micro-operations, architectural improvements may be possible that may provide the fastest execution path for that instruction that writing out individual instructions could ever provide. In short, CISC processors are more efficient at utilizing memory bandwidth which often translates to performance gains for memory intensive applications.

For example, to perform R1 = R2 + R3 + R4 + R5 + R6 and push the result onto stack, say the RISC code is written out as,

ADD  R1, R2, R3 (4-byte)
ADD  R1, R4, R5 (4-byte)
ADD  R1, R6, R0 (4-byte, R0=0)
PUSH R1         (4-byte)

and as such requires 16-bytes of space.

Coming to CISC, due to the possibility of different styles of encoding, the same information may be represented as follows...

ADD R1, R2, R3 (4-byte)
ADD R1, R4, R5 (4-byte)
ADD R1, R6     (2-byte)
PUSH R1        (1-byte) 

which takes only 12 bytes of memory. Thus, memory utilization is improved allowing the processor to see more instructions and thus reduce idle cycles.

  • 1
    $\begingroup$ This provides a useful perspective but also seems possibly slightly over-stated in its use of adjectives. "huge performance gains" - would you care to quantify that? Can you justify the "huge" part? Similarly for "much more information". $\endgroup$ – D.W. Jul 11 '15 at 2:34
  • 1
    $\begingroup$ I believe Linus Torvalds said a similar statement . Adjectives removed anyway. $\endgroup$ – Revanth Kamaraj Jul 11 '15 at 2:58
  • $\begingroup$ This is just not true. CISC does not reduce memory bandwidth. Register pressure maybe. $\endgroup$ – Jeff Hammond Jul 23 '15 at 4:31
  • $\begingroup$ Jeff, refer to Steve Furber's ARM soc architecture. $\endgroup$ – Revanth Kamaraj Jul 23 '15 at 15:55
  • $\begingroup$ Page 27 2nd edition ARM System On Chip architecture. $\endgroup$ – Revanth Kamaraj Jul 23 '15 at 16:09

An important aspect that no one has brought up thus is that almost all CISC CPUs are microcoded architectures. A microsequencer and a control store consume far less real estate than a hardwired controller, and the instruction set can be modified without modifying the hardware.

Microprocessors were novelty devices when I entered the field. A very common practice back in the seventies and early eighties was to assemble a CPU using bit-slice ALUs, a microsequencer-based control unit, and a control store into which the microcoded instruction set was either loaded or blown. These computers were based on 7400 series transistor-transistor logic (TTL). The 78181 4-bit ALU was used to construct a lot of processors, including the DEC PDP-11 and early VAX 11 computers, the Data General Nova, Xerox Alto, and the Wang desktop computer.

  • $\begingroup$ "An important aspect that no one has brought up thus is that almost all CISC CPUs are microcoded architectures." Yes and no. For instruction scheduling, modern CISC CPUs usually only resort to microcoded control for hard legacy CISC instructions (e.g. x87 transcendental instructions). On the other hand, even RISC chips occasionally use microcode control as an alternative to state machines for some subsystem (e.g. to control some specific unit). Indeed, the line between microcode and a state table can be fuzzy. $\endgroup$ – Pseudonym Jul 22 '15 at 0:59

You will have a hard time finding any desktop computer that isn't using an x86 compatible processor. That instruction set has beaten MIPS, it has beaten Sparc, it has beaten Alpha, it has beaten Titanic (I may have spelled that name wrong). MIPS on the other hand is barely existing today. So no matter what you think today, very clever people thought that the x86 instruction set was a really good idea, and they have made a ton of money with it.

Computers started as RISC because a complex instruction set was just beyond the abilities of implementors. If you want to see a RISC instruction set, look at the CDC 6400-6600 and CDC Cyber 170-175 instruction set. That's proper RISC. About 10 years ago I asked some chip designers how much space that would require (in the corner of a reasonable advanced GPU chip). They told me about 1mm2 - including the machine's RAM, which would take 99% of that space.

When people could build CISC machines, they were actually at an advantage. Remember that x86 was released long before MIPS, 1978 vs. 1985. At that time you needed processor cycles for reading instructions, decoding them, performing them. MIPS in 1978 would have taken four cycles per instruction, and per operation. If you take an x86 instruction like "add register to memory", that would take maybe 7 cycles for the instruction, but performing 3 operations. That was a major advantage. And the more different instructions you have, and the more powerful each instruction, the greater the advantage.

And when the x86 64 bit instruction set with its nightmarish prefix codes was developed, the complexity of the instruction set didn't matter anymore. CISC nowadays is just translated into RISC, and the whole translation business is maybe one percent of the chip.


This question has a lot to do with very recent trends in computing that favor a massive shift to mobile and tablet computing, thereby favoring RISC cpus, and has caught Intel (probably worlds largest CISC purveyor) at a disadvantage in a so-called "inflection point" exactly like the kind Grove drew attention to and warned of. The short story is that CISC seems to be starting to melt away under the massive paradigm-shifting/gamechanging onslaught of mobile computing because of its apparently intrinsically high energy consumption.

CISC will presumably always be around on the desktop but mobile is widely regarded as the new future of computing. Many developing countries (with large potential computer-using populations) will actually largely skip the desktop phase. See, for example, Rise and Fall of desktop computing

An excellent case study of this question is to read about Mike Bell who is working for Intel in a new position attempting to position Intel better in the mobile market via the Atom CPU via a "skunkworks"-like project/initiative, with very strong executive support. The mobile market is highly tightly coupled to RISC architecture, and mainly ARM processors, due largely to their high energy efficiency (power consumption), a new key criteria for computing which the question & no other answers mention. Here are two recent articles along these lines that reveal a lot of the internal corporate thinking (and ensuing scramble!) on the subject:


A factor not mentioned in other answers is economic. It is also about Intel. The CISC architecture is largely represented by the x86 and x64 families. These all descend from the humble 8088 used in the original IBM PC. The early market dominance of that series of computers meant that Intel had a solid revenue stream for R&D. Coupled with the fact that Intel was able to curb competition by reneging on/canceling it's second source agreements meant the CPU prices could rise to extreme levels ensure very rich gross profit margins.

Thus while other CPU manufacturers struggled to keep pace, Intel was able to pour billions of dollars into developing newer, faster products. The RISC competition could not spend nearly that much money. Many RISC processors went off the market. Some were:

DEC Alpha, Fairchild Clipper, AMD 29000, SPARC, MIPS, POWER (for PC use), Hitachi SuperH...

I recall pundits of that era announcing that the RISC vs CISC war was over and CISC had won. It had not. It just outspent everybody else.

Can this dynamic ever change? It already is. No economic advantage is absolute.

The one Achilles heel of the x86 is it's voracious appetite for power. This has allowed a smaller, more nimble competitor (ARM) to thrive in markets (like phones/tablets/etc) where energy thriftiness mattered.

A great video about this from a member of the ARM team is ARM Processor - Sowing the Seeds of Success - Computerphile at around 8:30

The second problem for x86 is the success of Intel's strategy. They managed to eliminate almost all competition. They slowed down. For years now, new Intel processors have delivered only very modest improvements. Worse still, super rich margins are a tough diet to give up for any corporation.

Today, ARM based Systems on Chip (SOC) and competing x64 chips from AMD are again making the CPU market an interesting place. (IMHO)

  • $\begingroup$ A slight correction is that the AM29000 did have a very successful run in aviation applications due to its unique feature of using two chips to verify correct operation. Planes often fly very high where radiation is an issue with causing glitches. So in this case special features beat cost and raw speed. $\endgroup$ – Peter Camilleri Dec 30 '20 at 23:42

There are many reasons one would choose to implement a CISC. The most prominent reason is for binary compatibility with an existing CISC instruction set. While software binary translation technology has improved, hardware-based compatibility has some technical advantages (as well as the disadvantage of less translation caching) and the less technical advantage of seeming more reliable.

Code density is perhaps the second most significant reason for choosing CISC. The Renesas RX was designed as a CISC specifically for code density as it targets microcontrollers where code memory size is a significant cost factor. Variable length instructions, complex instructions (mainly more addressing modes), implicit operands, and lower register count all benefit code density.

An historical (and in my opinion misguided) reason for choosing CISC was to close the semantic gap between programmers using a higher level language and the processor. Since complex instructions can generally be replaced by a sequence of simpler instructions, the complexity of a higher level language compiler for a RISC need not be much more complex than for a language-matching CISC. RISC avoids "semantic clash" (where a processor instruction does more or less work than a corresponding language statement) and facilitates strength reduction and scheduling optimizations. (See "What are the tradeoffs in compiler development effort related to CISC vs. RISC?" for more details.)

There can be a significant fixed cost associated with executing an instruction. This encourages the use of relatively complex instructions to spread this overhead over more actual work; reducing the dynamic instruction count can improve performance. When the cost of logic and RAM was much greater than the cost of ROM, the incentive for complex instructions was significant since an instruction was decoded by looking up microcode.

A reason to use CISC that is perhaps contradicted by historical evidence is that microcode can be optimized for each microarchitecture whereas standard libraries may be slow to exploit features of a new implementation. The optimization level of software implementations of memcopy versus that of the microcode for REP MOVSB implies that libraries can get more attention than microcode. Part of this may come from the processor vendor targeting a broader user base so justification of effort may be more difficult compared to open source or internal software where localized interests of developers or users can bias implementation effort.

Being able to ship an optimized standard library with the processor does have significant attractions. The storage and execution of a platform standard library can be significantly optimized by software-hardware codesign. The distinction between a complex instruction and a Platform Abstraction Layer call can be subtle (or non-existent). A RISC design could use the same implementation techniques for handling PAL calls as a CISC does for complex instructions, including using operations not provided in the general instruction set with specialized hardware, using clever caching and decoding, and specifying register operands (though a CISC would often use dedicated registers similar to a per-function ABI). The mental model associated with CISC can encourage such optimizations. In addition, users may be less offended by the forced inclusion of a "hardware" standard library (CISC) than by forced inclusion of a specific PAL library.

Decoding relatively complex instructions can have less overhead (and possibly more reliably be correct in discerning intent) than the comparable RISC technique of idiom recognition where a sequence of instructions is recognized as a semantic unit. This overhead difference would be most noticeable in a smaller implementation, but the overhead to use this information reduces the significance of the decode savings.

Additional contextual information can facilitate hardware optimization. For example, when incrementing a value in memory, hardware could recognize that the memory address is used twice (for the load and the store) providing an opportunity for cache way memoization and translation caching. Complex instructions can provide such information explicitly. In a complex instruction, intermediate values have an explicit lifetime (that of the instruction); with a traditional RISC register values must be explicitly overwritten to indicate the end of liveness. (Note: A RISC could specify a register which is always zeroed after each use, providing a means to specify a single-use temporary value. Such instructions would be moderately more complex.)

If implementation details are not hidden behind an abstraction layer, it becomes more difficult to use different microarchitectures to optimize for different tradeoffs. Exposing microarchitectural details as architectural guarantees locks the microarchitecture into the compatibilty guarantee. While PAL software could be optimized the same as complex instructions, such requires hardware-software codesign. Organizational separation and diversity make codesign more difficult.

Complex instructions can provide guarded access to privileged state. For example, complex instructions are often atomic with respect to interrupts. While a RISC instruction set could provide a user-level mechanism to temporarily suspend interrupts, possibly even something like linked-load so that software explicitly retries the operation if interrupted, providing such is not typical for RISCs.

Similarly, a complex instruction could provide controlled access and/or use of privileged information. Because the executed operation has controlled semantics, actual privilege violation can be avoided. RISC-oriented alternatives include PAL code (which typically has significant overhead) and masked access to configuration registers (or shadow copies of registers) that have some privileged state. Providing a general solution (RISC) is more difficult than providing a solution to one or a few special cases (CISC), but is more powerful and less vulnerable to accumulation of special cases. If one believes that the important special cases are few, CISC can be more attractive.

Complex instructions can also hide state from software. One prominent advantage of such would be for context saving and restoring. With instructions that save and restore state, the architecture only needs to communicate the context size to the OS not the specific mechanisms for transferring state to memory. This allows applications running on a legacy OS to use ISA extensions which add state. (Again, PAL software could provide the same functionality.)

Much of the complexity of x86 comes from compatibility across many extensions. With complex and less orthogonal instructions (useful for code density), removing some work that turned out not to be commonly needed, avoiding unnecessary dependency chains (e.g., only one carry bit, only one dynamic shift amount register), adding some work that turned out to be commonly used and that can be optimized within the complex instruction — any of these would require adding a new instruction and making the ISA less aesthetically pleasing.

In many cases a RISC would not encounter such issues because instructions are highly orthogonal and primitive. In some cases a RISC might need to add new primitives but such would typically be applicable to more than one use.

In addition, once the infrastructure is in place to support complex instructions, the barriers are reduced for additional complex instructions. That is, much of the cost of complex instructions in non-recurring. Strongly RISC ISAs suffer a complementary hinderance to introducing CISCy features.

The frequency of extension of x86 may also be partially attributed to its popularity for general-purpose computing and the merchant processor model (these also increase the importance of binary compatibility). RISC ISAs have often been tied to sysem vendors which encourages a narrower focus on applications and the lack of competition for implementations of a specific RISC ISA somewhat discourages the use of instruction set extensions for marketing. Popularity also makes the cost of developing new extensions less significant (non-recurring expenses are less important at higher volume).

The x86 compatibility philosophy probably also biases toward extending existing mechanisms rather than providing a more clean break which means that new features are more influenced by existing features. Higher frequency of extension also encourages more incremental changes, which encourages reusing mechanisms, tending to reduce orthogonality.

Comparing an academic presentation of classic MIPS (which is a subset of modern versions of MIPS and excludes various optional ISA extensions) to modern x86 (which traces binary compatibility back to the 16-bit 8086 and assembly-level quasi-compatibility even further back) with all its historical baggage does not present the best case for CISC nor a realistic case for RISC.


Simply before there were Reduced Instruction Set Configurations there were Instruction Set Configurations. They have their applications. particularly in very large memory block transfers with high capacity chipsets, which would only need 4-16 bytes to transfer an entire video page, instead of an long for ever loop. that is changing and RISC is becoming the status quo as chip sets are becoming more sophisticated, like the incredible GPU's found in the high end video cards.


CISC cpu has more advantages than RISC. Because CISC use less hardware register and XNOR/XOR gates than RISC many times!!!! Imagine the instruction bytes in CISC will be executed-sequence, there is only one logic gate and register is used. If 1 bilion transistors can produce about 300 million logic gates, so you can process 300 milion operators or processes (IF, equal, mathematic, variable, addressing... etc) and more program can run in CISC. But in RISC, it takes dozen times of logic gates for running a program in pipelined design. So 300 milion x 50 times (50 instructions) + 15000000000 bit counters!!! in so-called RISC. CISC use more hardware to reduce software algothrim which slow down the cpu.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.