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?


10 Answers 10


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$ – Wyatt8740 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...

  • 1
    $\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$ – Wyatt8740 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
  • $\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 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)


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.