What was it about, and does it matter today?
RISC first appeared on the market in the form of IBM 801 derivatives for embedded use. However, it wasn't until 1986 when the ball really got rolling when the first RISC processors appeared from HP, MIPS, and Acorn (the first ARM development board).
There was some debate at the time about if RISC could outperform CISC because the higher number of instructions that RISC processors required. This debate was ended in 1987 where the first SPARC based Sun workstation appeared at 3 times faster than the previous CISC Motorola 68020 based model. The 68030 appeared the same year but the SPARC was still twice as fast.
At the time, Motorola pretty much owned the workstation market with the 68K line. The bigger workstation vendors jumped ship to the faster RISC designs pushing 68K down to the desktop and embedded market, though it did continue to see some use in workstations along with some Macs, Amigas and STs.
Motorola did their own RISC processor, the 88000 series, and this was chosen by both Apple and Steve Jobs' NeXT Computer [88K]. However, the initial 88100 was a very expensive multi-chip system and both companies elected to wait until the next generation 88110, a single chip version. This chip was late and by then IBM had approached Apple and Motorola to team up for PowerPC. Both Apple and NeXT would then jump to PowerPC, but NeXT abandoned hardware before their PowerPC machine shipped.
Aside from being fast, the RISC processors were cheap to make because they relatively simple to develop and physically small. To put it into perspective, The ARM 2 is competitive with the initial Intel 386s, yet the ARM had one ninth of the transistors and was only one third of the size, and that's with the 386 a process node ahead.
From 1986 and onwards into the 90s RISC took over the workstation and server market. Intel got bigger and bigger on the desktop but didn't have a look-in on the workstation market. Intel's attempt at build their own answer to the RISC onslaught was a RISC/VILW processor called the i860. It was reportedly very fast, but rather complex to program. It was not a great success but it turned out to be surprisingly good for graphics and was used as an graphics accelerator by both NeXT and Silicon Graphics.
In 1992 after a number of internal RISC projects, DEC, producer of the decidedly CISC VAX machines introduced the Alpha 21064 EV4 processor where EV either denotes the silicon process or is a reference to an experiment involving and electrically charged pickle! [EV]. The Alpha was an absolute monster of a processor coming in at almost 200MHz when most processors were not even at 100MHz. DEC would rapidly ramp its clock speed over the next few years leaving all the other vendors playing catch up.
As development continued on the RISC side, CISC vendors did not stand still. They started introducing some of the concepts and features associated with RISC designs into their CISC processors. Adding these kinds of features to a CISC architecture was thought to be impossible, but that didn't stop smart engineers.
The 486 and 68040 both introduced pipelining, this provided large per-clock performance improvements over their predecessors.
The successors to the 486 and 040, the Pentium and 68060 used more RISC like techniques, and especially superscalar execution, to boost performance.
The 68060 in particular is quite literally a RISC processor with CISC fetch & pre-decode stage. It removed microcode entirely and puts instructions through a pre-decode stage that outputs fixed length instructions. To quote the 68060 User Manual:
"Fixed format instructions are dispatched to dual four-stage pipelined RISC operand execution engines". [060UM]
Intel was similar but not quite so RISCy with the Pentium. Startup NexGen did something more like the 060 and created a processor with an x86 decoder and a RISC core. This was sold as the Nx586. NexGen was later bought by AMD.
RISC was a single design philosophy but from early on, there were always some different approaches to building RISC processors. The SPARC (based on the Berkeley RISC I/ II) included a feature called register windows to speed up context switching. None of the other mainstream RISC designs used this technique.
One big difference resulted in the Brainiac vs. Speed Demon debate. The early IBM Power processors ran at a relatively low frequency but included Out-of-Order execution to achieve high performance.
Other vendors went with simpler designs and relied on a high clock frequency to achieve their performance. The flagship for this approach was the DEC Alpha which was the fastest processor on the market for quite some time. However, this debate didn't last too long, the third generation Alpha 21264 also want Out-of-Order in 1998.
This debate was also repeated on the desktop when Intel's Pentium 4 went with a very high clock. Intel eventually abandoned this approach when it became obvious that very high clocks require rather high power consumption. Graphs of the day pointed out that temperatures were scaling up so quickly that they'd eventually hit the temperature of the surface of the Sun. The following Core processors didn't require such high clocks for performance and were low power enough to find a home in laptops.
RISC proceeded to take over the workstation and server markets and make inroads into the embedded market (which 68K still ruled). Games consoles started using RISC processors which could provide high performance at a low price:
In the 1990s many companies were designing and building their own processors RISC or otherwise. One company however did things somewhat differently. UK desktop computer company Acorn developed the Acorn RISC Machine (ARM) processor for a successor to the BBC Micro computer that had been highly successful in the education market in the UK in the 80s.
The first ARM was designed to be low power to save cost on the packaging, but turned out to be even lower power that expected. This fact serves Arm well to this day and became a defining feature of the processors and indeed Arm the company.
Pressure from Acorn's competitors and a deal with Apple for a CPU for the Newton led to Arm being split off as an independent company (now called Advanced RISC Machine). Unlike most CPU vendors, Arm didn't build it's own processors. They designed the processors and then licensed the designs to other companies.
This led to Arm getting into some of the bigger companies with their own designs and replacing them from the inside. Those companies would then become Arm vendors. Arm vendors essentially became a salesforce for Arm.
Arm did reasonably well as a small company displacing 8 and 16 bit processors, but they hit a problem. The 8 and 16 bit processors often used smaller instructions that meant code could be very small, Arm only used fixed 32 bit instructions so compiled code was bigger. This meant anyone considering Arm might have to increase memory in their device, increasing product costs. This came up in a visit to Nintendo who found using Arm would have made game cartridges use more memory making them uneconomic [ARM-H].
Arm's then chief architect Dave Jaggar proposed a solution to this: Add a 16 bit instruction mode called Thumb. This idea initially met with a great deal of resistance within Arm as it was considered as going against RISC ideals. This however was for a good purpose and in this case code density was critically important. The proposal eventually won out and It was added without adding a great deal of complexity to instruction decoding, i.e. it was done in a RISC way [ARM-H].
The resulting ARM 7TDMI processor went on to be highly successful after the then No.1 mobile phone manufacturer Nokia started using it. The rest of the Mobile industry copied Nokia and Arm took off. Arm is in pretty much every mobile phone now, and almost everything else too!
Despite the 68K series taking on many RISC characteristics over time, the inherent complexity of implementing the CISC 68K instruction set remained. In the 1990s this ultimately made the Motorola 68K series processors uncompetitive against RISC competitors in workstation, desktop, and eventually embedded markets. This can be illustrated by comparing the final top end 68K, the 68060 to some of its contemporary processors, specifically a number of MIPS processors:
The Motorola 68060 is essentially a superscalar RISC processor with a CISC decoder. The pipeline is divided into 2 halves, the first 4 stages fetch and pre-decode 2 instructions per cycle. The second 4 stages then decode and execute the instructions.
The MIPS R8000 has a 5 stage pipeline and also does fetch and pre-decode, but this is done in a single pipeline stage. However, this stage fetches and decodes 4 instructions at a time.
The difference I want to illustrate here is the simplicity the R8000 has in getting its instructions. It reads 128 bits into an instruction buffer. It doesn't need to calculate any instruction lengths or positions, these are already known because the instructions are a fixed length. Instructions also cannot cross cache lines or memory pages, so problems associated with those are non-existent.
The 68060 avoided cache and memory page issues by pulling multiple instructions into a relatively large buffer. It then has to partly decode an instruction to get its length so it can fetch instructions from the buffer. The 68K series has a myriad of instruction formats to deal with so there are potentially thousands of instructions of various different lengths. In the 68060 these are pre-decoded and converted into fixed length instructions for execution. The fetch / pre-decode unit occupies approximately 20% (40 mm2) of the entire 200 mm2 chip area.
RISC chips didn't need anything nearly as big and complex as the 68060 fetch / pre-decode unit so they could either make a smaller (cheaper) chip or use the area for something else.
Another contemporary of the 68060 is the MIPS R4400. Its relatively simplicity enables a much higher clock rate (it scaled to 250MHz) and twice the cache, it gave twice the performance on the SPEC Int 92 benchmark at 150MHz. This wasn't even the fastest processor at the time, the Alpha 21064A at 275 MHz gave numbers twice as high as the R4400 on SPEC int 92 [SPEC].
Since the 68060 was ultimately positioned for the embedded market, a comparison with the MIPS R4200 is valid as it was also designed for embedded use at the same time.
The R4200 had similar performance to the 68060 but ran at lower power and sold for around $50, just 1/6 of the price of the 68060.
Within 2 years, DECs implementation of ARM, the StrongARM had appeared with double the performance and power usage under 0.5 Watts. It cost $29 in volume.
No, the 68060 was certainly a worthy successor to the 68040, and was competitive (per clock) with Intel's Pentium which was considerably more expensive. At the time I was using a 68030 accelerated Amiga, a 68060 would have been awesome!
The problem was, the inherent complexity in the 68K's CISC instruction set had a high cost in the size and complexity of the processor design. Without the same level of complexity, RISC chips could be clocked much faster. More importantly, because of their simplicity they could be much smaller and sell for a much lower price. CISC designs simply became uncompetitive.
CISC may have had an advantage for code density, but there's no point saving a little money on the memory system if the cost of the CPU is multiple times higher.
The 68060 did get some embedded design wins and was in production for several years, it was also briefly used in an Amiga where it provided a good performance boost over the 68040. Later revisions of the chip proved highly overclockable going well beyond the fastest 75MHz version produced [Lightroom], and are still sought after by classic Amiga enthusiasts to this day.
Binary compatibility wasn't important on workstations as recompilation was usual.
It also wasn't very important in the embedded market where processor requirements can differ wildly. Backwards compatibility could have been important as the 68K was present in Macs at the time, however Apple had already decided to go RISC.
Commodore and Atari also both used 68Ks in the STs and Amigas but neither used the 68060. Commodore were planning to go with a RISC processor in a follow up to the Amiga called Hombre but the company didn't survive long enough to make it [HOMBRE].This lack of a compatibility requirement in the markets 68K made the 68K line a lot more vulnerable to the RISC advance. Had backwards compatibility been more important, the next generation probably would have likely taken the same direction as the Pentium Pro and would have gained some ground back against the RISC processors.
One area where binary compatibility is critical is the desktop, it's no coincidence this is the one area where a CISC instruction set lives on to this day. Without binary compatibility, it was very difficult for any of the RISC competition to challenge the dominance of x86 in desktops.
The DEC Alpha did have a technology called FX32! that could emulate an x86, in some cases faster than the x86 processors of the time. Had Alpha been pushed down into the desktop market this could have changed things, but DEC kept the Alpha in the high end market instead ...and went bankrupt.
As much as technical differences were important, it was the markets that the 68K line served that made its downfall inevitable. For x86, it's the markets that those processors served that ultimately kept it going.
The 68K line didn't end with the 68060. The 68K was even more RISC-ified into the Coldfire processors with pretty major changes to the instruction set enabling much higher clock frequencies. These would continue in active development for another decade.
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
© Nicholas Blachford 2026