What was it about, and does it matter today?
Edition 1.05 - 25/7/26
© Nicholas Blachford 2026
Note: This article is mainly intended for those with an interest in microprocessors and uses standard industry terms. A glossary is included to explain some of these if you are unfamiliar with them.
Reduced Instruction Set Computer (RISC) was a processor design philosophy that started in the late 1970s in opposition to the increasingly complex designs of the day [MAIN].
The paper that coined the term RISC was published way back in 1980 [RISC].
In the following years, RISC processors would come to dominate the workstation, server and embedded markets. Today it dominates the entire CPU industry, apart from the desktop and servers, but it's making inroads there.What people think RISC was about seems somewhat divorced from its origins. There is talk of RISC principles, pure RISC, everything must be done in a single cycle etc. I've even heard the idea that modern RISC processors are actually now Complex Instruction Set Computer (CISC)s because they have many more instructions these days. These are largely references to implementation details [RISC-I], or a misconception of what RISC originally was.
The name doesn't help, Reduced Instruction Set Computer sounds like the goal was just about removing instructions. In reality the acronym was devised by David Patterson and Carlo Sequin on the way to a funding meeting because it sounded like "high risk" [RETRO].
RISC really started with three tenets:
The original paper argued that these three changes would make for smaller, simpler, and faster processors. The concept did involve reducing the number of operations a processor had, but it was really about making processors smaller and faster by removing complexity.
In addition to the above tenets, I would add a fourth. This was there from the beginning, but I don't think its importance would become obvious until implementations began to appear:
Microcode dates back to the beginning of computers when they were large, the hardware rudimentary, and memory was very small and expensive.
Microcode was software routines inside the processor that implemented instructions, essentially mini programs complete with conditional jumps and subroutines, that ran in the processor [MCODE]. This did not operate in the way you might think however. Instructions were not decoded then executed. Microcode instructions directly controlled the hardware, with bit patterns in different parts of the microcode instructions controlling different parts of the processor.
Microcode enabled more complex operations to be added to the instruction set relatively easily, increasing capabilities while saving memory. For example, some processors didn't have hardware multipliers but you can implement a multiply in software using multiple adds. If you were to implement that algorithm in microcode you could then include a multiply instruction in the processor's instruction set.
Another use of microcode was to enable compatibility across different machines. To reuse the previous example, high end machines might have a hardware multiplier, and the instructions to use it. Lower end machines without the hardware might use microcode. This meant you could use the same software on both machines, despite the hardware differences.
Assembly code programming was much more common in the 1970s and before, so instruction sets were made to be programmer-friendly [68K]. Instructions were made to be "orthogonal", that is, any operation can use any instruction format. This meant there were lots of different ways of doing the same operation, and each of these were represented by individual instructions. Processors were also adding high level instructions. Functions that you might find in a software library were implemented as microcode inside the processor. Some machines went all out and included things like the OS and compiler in hardware [HLLCA].
Microcode makes a lot of sense for ease of programming and code density, but as more and more instructions were added, it made the processors ever-more complex. When memory was slow, it was initially a way to speed up processors, but as memory got cheaper and faster, and processor complexity increased, this turned on its head.
The complex instructions added an unavoidable overhead, they had to be decoded and identified, then the microcode engine would have to be initiated and then the microcode program would then be executed. All of these operations were sequential, there was no way to do other operations at the same time. Even basic pipelining was difficult.
On top of this, there was additional complexity when memory management operations were involved or interrupts occurred. What do you do if an interrupt comes in in the middle of executing a microcode program? This required intermediate processor state to be saved and restored, adding another level of complexity to already complex processors.
All this complexity meant that processors took longer and longer to design and debug. When the machines did ship, they would still have bugs. The bugs became so bad that processor vendors took to including special memories in the processor just to hold microcode patches. Bizarrely, this gave us the floppy disc. IBM invented it as a way to distribute microcode patches [RETRO].
The delays pushed out development times from months to years. The original RISC paper notes that both the Z8000 and 68000 microprocessors were 1-2 years late because of their microcode complexity.
High level instructions were added to make things easier and faster for programmers, but it's not clear if this always worked. When the VAX's INDEX instruction was replaced by a set of simpler instructions, it ran 45 percent faster [RISC].
Microcode is an example of a powerful technology that was a good solution to the problems of its time. However, by the late 1970s, computers were far more sophisticated and memory was becoming faster and cheaper. Compiled languages were also becoming more common and they tended to avoid complex instructions. The technical environment had changed and thus the problems that would present, and the solutions to them, had changed.
The original RISC paper argued removing microcode would make processors simpler, easier to develop, and faster.
One of the tenets of RISC is to do operations using internal registers in place of using memory directly. Some CISC instructions let you specify the memory address of data alongside the operation in instructions.
RISC processors on the other hand use what is known as a load-store architecture. The data is explicitly loaded into the processor registers before any operations are performed on it. This means more instructions, but it's faster. In fact, experiments on programming existing systems found that they could get speed-ups just by using the registers more [801]. Further experiments showed that when a compiler was designed to use registers more with simpler instructions, it would be significantly faster, even on existing hardware.
The third tenet of RISC was to remove under-used instructions.
As more and more higher level languages were being used, it was found that all the nice orthogonal different versions of instructions added for the benefit of assembly programmers, were not being used.
On top of that, the complex instructions that went to microcode were also not used by the compilers.
Compilers tended to use the fastest instructions they could use, preferably those that would be fastest across as many versions of the processor as possible. This meant compilers tended to use only a small subset of the instructions available in the instruction set. Many of the more complex instructions were not used at all.
The consequence of this was you could simply remove the majority of the processor instructions and no one would notice them missing. Well, maybe apart from the odd irate assembly programmer.
The RISC processors did exactly this and that is partly where the name comes from. However, just reducing the number of instructions appears to be one of the least important aspects of the RISC philosophy. It was much more about removing complexity and reversing the direction away from adding high level language features.
I would like to clarify a point here, since this seems to cause some confusion.
I'll define the terms as I use them:Operations
The basic hardware functions a processor performs. For example: A 32 bit add.
Instructions
The commands you use to initiate operations. These are what the Instruction Set Architecture (ISA) defines.
There may be a single 32 bit add operation, but many different instructions that use that add.
Tenet 3 essentially says: "Why have 8 different add instructions when the compiler only uses 2?" This is what is meant by "reduced instruction set".Note that RISC was never about reducing the number of hardware operations.
When RISC processors moved into real development from theory, the ideas and end results shifted somewhat. Beyond removing microcode, surplus instructions and using registers, it soon became about removing complexity in general, especially in the instruction set. Decode in particular was targeted, though this was not mentioned in the original RISC paper.
The developers of the MIPS-X research processor took up a maxim to cover this:
While this may seem a touch extreme, it worked. The results of the MIPS-X processor resulted in 25% larger binaries, but delivered enormous performance gains [MIPS-X]. These results were also born out in real commercial designs, the DEC Alpha had larger binaries even compared to other RISC designs, but it was the performance leader for much of the time it was in production.
This may seem an odd question to ask but one thing that can be slightly confusing about the RISC vs. CISC debate is that CISC was not given a definition at the time. RISC was a reaction to increasing complexity of designs, The RISC-I paper [RISC-I] points to 3 systems: DEC VAX, Intel iAPX-432 and IBM System 38. Notably, the Intel 8086 was listed as an example of a simpler design!
In a retrospective of the RISC-I paper, the authors state:
"I think the trade press concluded that any commercial computer that wasn’t a RISC must be a CISC, and hence the confusion" [RETRO].
Computer Architecture: A Quantitative Approach defines CISC as:
"A Complex Instruction Set Computer (CISC) is a computer architecture in which single instructions can execute several low-level operations (such as a load from memory, an arithmetic operation, and a memory store) or are capable of multi-step operations or addressing modes within single instructions" [CISC].
John Mashey argued that new architectures from 1986 onwards shared a set of characteristics that previous designs did not. He gave more detail on the concrete differences between actual RISC and CISC processors [Mashey].
While CISC wasn't really defined, It's also true to say RISC never had a tight definition either. The tech press would eventually invent their own definition, correct or not and this led to things like single-cycle instructions being part of the definition, or even the idea of pure RISC.
In reality, RISC is a design philosophy, an approach to processor design. Single-cycle instructions were part one or two implementations but never required. Without a concrete definition, there is not really such a thing as a pure RISC, though perhaps it could be a processor that follows the RISC philosophy very closely.
RISC was the result of multiple developments, the biggest being IBM's experimental 801 processor(s) led by John Cocke [801].
The 801 initially started in 1974 as a project to build a telephone switch that could handle 300 calls per second. This required 12 mips Million Instructions Per Second (MIPS) when the fastest IBM computer at the time could only do 3.5 mips.
The project looked at what was required and found it didn't really require that many instructions, so they designed a very stripped back processor for the task. The telephone switch project was terminated the following year, but the design was advanced enough that it was expected to perform very well in a number of areas. Consequently, it was kept going with the aim of producing a more general purpose design.
Using a simple design and only concentrating on a limited set of instructions, made for a relatively simple but very fast processor, with many operations able to be completed in just 1 clock cycle.
Research showed that the majority of code typically used a fraction of an instruction set and most of this (> 50%) was based on just 5 instructions. This meant that this simple machine was capable of doing what the much more complex machines could do. You just had to code it yourself instead of relying on microcode. A compiler could generate the same sequence of operations as instructions and on this simpler, faster design. It would then run faster than the complex machines with microcode.
John Cocke wrote:
"Imposing microcode between a computer and its users imposes an expensive overhead in performing the most frequently executed instructions." [801]
The 801 was a pure load-store machine with 16 registers, it had pipelining and a split instruction / data cache. There was no microcode and instructions used a single fixed 3 byte format.
Some lessons were learned from the first machine so a second version was designed. One finding was analysis of the code and performance showed the compiler was spilling registers to memory so the second version increased the number to 32 registers and a fixed 4 byte instruction size. This set a pattern that would be used by many subsequent commercial RISCs. Even the recent Advanced Performance Extensions (APX) proposal for x86 includes 32 registers [APX].
The 801 processor was extremely fast for its day, some of this is due to its load-store nature. Bizarrely, in some cases, code running on a 801 simulator running on an IBM 370/168 would run faster than native code on the same machine! This sounds incomprehensible, but if the simulator was mapping directly to the faster, simpler instructions in the 370, and the existing native compilers used the slower, complex instructions, it does make some sense.
The 801 compiler was then ported to the 370 but only used simple instructions and kept the load-store method of working. The resulting code ran up to 3 times faster than the existing 370 compilers. So, it turns you can get substantial performance benefits just by treating a CISC machine like a RISC machine.
The 801 was an internal project at IBM with little published about it initially, but other projects were coming to similar conclusions. Some of these led to the original RISC paper.
After his PhD, David Patterson spent some time working on DEC's highly complex microcode. He proposed building a single chip VAX computer but it would require a way to patch the often buggy microcode. His paper for this was rejected on the ground that such a store would be a waste of silicon, he appeared to agree so he began looking at simpler instruction sets without microcode [RETRO].
Another inspiration for the original RISC paper was David Ditzel's work with the SYMBOL computer. This was an example of a High Level Language Computer Architecture that used hardware to replace software. It implemented the OS, compiler, and even a text editor in 20,000 hardware chips [HHLCA].
The conclusions of working with this machine were multifold, it was slow, buggy (it took several years to debug) and difficult to optimise for. A conference presentation by Ditzel sums it up:
"Fascination studying SYMBOL (Ditzel/Patterson) eventually led both to religious conversion to RISC". [Ditzel]
This ultimately led to the 1980 paper "The Case for the Reduced Instruction Set Computer" by David Patterson and David Ditzel [RISC] that introduced the RISC and CISC concepts to the world and gave us the acronyms.
Others beyond the authors of the original RISC paper also came to the conclusion that simpler machine were better:
Stephen Johnson at Bell labs did a project to to optimise a processor by iterating over a process of proposing designs then building a compiler and measuring the results. This also resulted in a relatively simple RISC-like design. [SCJ]
Andrew Tanenbaum (of Minix fame) proposed a simpler machine in 1978.
His research was designing a machine as a compiler target. This was based on analysing thousands of lines of code and designing a machine around it. This resulted in a simple instruction set that while variable-length, would have been relatively easy to decode. [EM-1]It turned out that the idea of simplification for performance was not new, some had already been done ...a long time ago. [6600]
The Seymour Cray designed CDC 6600 supercomputer used 2 sizes of instructions, a simple instruction set and no complex microcode way back in 1964. It was the fastest computer in the world until 1969 when the CDC 7600 came out. The backronym "Really Invented by Seymour Cray" is not without some merit!
Some consider the 6600 as non-RISC because it doesn't use a single length length of instructions, however I don't think this is quite true. The 6600 uses a fixed 60 bit packed format with some variations on the number of instructions within, so technically yes, they're more than one length but what's important is that decoding is predictable and simple. This fits perfectly with the RISC philosophy.
There was a lot of resistance to the initial RISC proposals and the 801 wasn't public at this point so the RISC proponents couldn't point to that work as an example. Building a processor would act to publicly prove the concept.
After returning to the University of California (UC) Berkeley from DEC, David Patterson supervised research into a new processor design based on the RISC concept. This became known as the Berkeley RISC-I [RISC-I]. This was the first time a University had designed a processor so it was an ambitious project to say the least [RETRO].
The RISC-I was followed by RISC-2, and it would go on to serve as the inspiration for the Sun SPARC processor.
Not to be outdone, Stanford University also decided to design their own RISC chip known as the Microprocessor without Interlocked Pipeline Stages (MIPS)*.
The designers decided to directly commercialise this project and founded MIPS Computer Systems.
* That won't be confused with the benchmark, honest.
RISC vs. CISC at 46, Section A
RISC vs. CISC at 46, Section B
RISC vs. CISC at 46, Section C
RISC vs. CISC at 46, Section D
RISC vs. CISC at 46, Section E
PDF: https://blachford.info/computer/RISC_VS_CISC_at_46/RISC-vs-CISC_at_46.pdf
Front page: https://blachford.info/computer/RISC_VS_CISC_at_46/index.html
© Nicholas Blachford 2026