Why would anyone want CISC?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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...

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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:

• Intel dismisses ‘x86 tax’, sees no future for ARM or any of its competitors

• An Empire Strikes Back: Intel Muscles Into the Mobile Market

Answer 8

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)

Answer 9

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.

Answer 10

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.

Answer 11

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.