Features —

RISC vs. CISC: the Post-RISC Era: A historical approach to the debate

Ars takes a look at the RISC vs. CISC debate in the post-RISC era.

Framing the Debate

The majority of today's processors can’t rightfully be called completely RISC or completely CISC. The two textbook architectures have evolved towards each other to such an extent that there’s no longer a clear distinction between their respective approaches to increasing performance and efficiency. To be specific, chips that implement the x86 CISC ISA have come to look a lot like chips that implement various RISC ISA’s; the instruction set architecture is the same, but under the hood it’s a whole different ball game. But this hasn't been a one-way trend.  Rather, the same goes for today’s so-called RISC CPUs. They’ve added more instructions and more complexity to the point where they’re every bit as complex as their CISC counterparts.  Thus the "RISC vs. CISC" debate really exists only in the minds of marketing departments and platform advocates whose purpose in creating and perpetuating this fictitious conflict is to promote their pet product by means of name-calling and sloganeering.  

At this point, I’d like to reference a statement made by David Ditzel, the chief architect of Sun’s SPARC family and CEO of Transmeta.

"Today [in RISC] we have large design teams and long design cycles," he said. "The performance story is also much less clear now. The die sizes are no longer small. It just doesn't seem to make as much sense." The result is the current crop of complex RISC chips. "Superscalar and out-of-order execution are the biggest problem areas that have impeded performance [leaps]," Ditzel said. "The MIPS R10,000 and HP PA-8000 seem much more complex to me than today's standard CISC architecture, which is the Pentium II. So where is the advantage of RISC, if the chips aren't as simple anymore?"

This statement is important, and it sums up the current feeling among researchers. Instead of RISC or CISC CPUs, what we have now no longer fits in the old categories. Welcome to the post-RISC era.  What follows is a completely revised and re-clarified thesis which found its first expression here on Ars over a year ago, before Ditzel spoke his mind on the matter, and before I had the chance to exchange e-mail with so many thoughtful and informed readers.

In this paper, I'll argue the following points:

  1. RISC was not a specific technology as much as it was a design strategy that developed in reaction to a particular school of thought in computer design.  It was a rebellion against prevailing norms--norms that no longer prevail in today's world.  Norms that I'll talk about.

  2. "CISC" was invented retroactively as a catch-all term for the type of thinking against which RISC was a reaction.

  3. We now live in a "post-RISC" world, where the terms RISC and CISC have lost their relevance (except to marketing departments and platform advocates). In a post-RISC world, each architecture and implementation must be judged on its own merits, and not in terms of a narrow, bipolar, compartmentalized worldview that tries to cram all designs into one of two "camps."

After charting the historical development of the RISC and CISC design strategies, and situating those philosophies in their proper historical/technological context, I’ll discuss the idea of a post-RISC processor, and show how such processors don't fit neatly into the RISC and CISC categories.

The historical approach

Perhaps the most common approach to comparing RISC and CISC is to list the features of each and place them side-by-side for comparison, discussing how each feature aids or hinders performance. This approach is fine if you’re comparing two contemporary and competing pieces of technology, like OS’s, video cards, specific CPUs, etc., but it fails when applied to RISC and CISC. It fails because RISC and CISC are not so much technologies as they are design strategies--approaches to achieving a specific set of goals that were defined in relation to a particular set of problems.  Or, to be a bit more abstract, we could also call them design philosophies, or ways of thinking about a set of problems and their solutions. 

It’s important to see these two design strategies as having developed out of a particular set of technological conditions that existed at a specific point in time. Each was an approach to designing machines that designers felt made the most efficient use of the technological resources then available. In formulating and applying these strategies, researchers took into account the limitations of the day’s technology—limitations that don’t necessarily exist today. Understanding what those limitations were and how computer architects worked within them is the key to understanding RISC and CISC. Thus, a true RISC vs. CISC comparison requires more than just feature lists, SPEC benchmarks and sloganeering—it requires a historical context.

In order to understand the historical and technological context out of which RISC and CISC developed, it is first necessary to understand the state of the art in VLSI, storage/memory, and compilers in the late 70’s and early 80’s. These three technologies defined the technological environment in which researchers worked to build the fastest machines.

Storage and memory

It’s hard to underestimate the effects that the state of storage technology had on computer design in the 70’s and 80’s. In the 1970’s, computers used magnetic core memory to store program code; core memory was not only expensive, it was agonizingly slow. After the introduction of RAM things got a bit better on the speed front, but this didn’t address the cost part of the equation. To help you wrap your mind around the situation, consider the fact that in 1977, 1MB of DRAM cost about $5,000. By 1994, that price had dropped to under $6 (in 1977 dollars) [2]. In addition to the high price of RAM, secondary storage was expensive and slow, so paging large volumes of code into RAM from the secondary store impeded performance in a major way.

The high cost of main memory and the slowness of secondary storage conspired to make code bloat a deadly serious issue. Good code was compact code; you needed to be able to fit all of it in a small amount of memory. Because RAM counted for a significant portion of the overall cost of a system, a reduction in code-size translated directly in to a reduction in the total system cost. (In the early 90’s, RAM accounted for around %36 of the total system cost, and this was after RAM had become quite a bit cheaper [4].) We’ll talk a bit more about code size and system cost when we consider in detail the rationales behind CISC computing.


David Patterson, in a recently published retrospective article on his original proposal paper for the RISC I project at Berkeley, writes:

‘Something to keep in mind while reading the paper was how lousy the compilers were of that generation. C programmers had to write the word "register" next to variables to try to get compilers to use registers. As a former Berkeley Ph.D. who started a small computer company said later, "people would accept any piece of junk you gave them, as long as the code worked." Part of the reason was simply the speed of processors and the size of memory, as programmers had limited patience on how long they were willing to wait for compilers.’ [3]


The compiler’s job was fairly simple at that point: translate statements written in a high level language (HLL), like C or PASCAL, into assembly language. The assembly language was then converted into machine code by an assembler. The compilation stage took a long time, and the output was hardly optimal. As long as the HLL => assembly translation was correct, that was about the best you could hope for. If you really wanted compact, optimized code, your only choice was to code in assembler. (In fact, some would argue that this is still the case today.)


The state of the art in Very Large Scale Integration (VLSI) yielded transistor densities that were low by today’s standards. You just couldn’t fit too much functionality onto one chip. Back in 1981 when Patterson and Sequin first proposed the RISC I project (RISC I later became the foundation for Sun’s SPARC architecture), a million transistors on a single chip was a lot [1]. Because of the paucity of available transistor resources, the CISC machines of the day, like the VAX, had their various functional units split up across multiple chips. This was a problem, because the delay-power penalty on data transfers between chips limited performance. A single-chip implementation would have been ideal, but, for reasons we’ll get into in a moment, it wasn’t feasible without a radical rethinking of current designs.

You must to comment.