The two stories of RISC

April 30, 2013

I said this implicitly in my entry on ARM versus other RISCs but I've realized that I want to say it explicitly: there are (or were) effectively two stories of RISC development. You could see RISC as a way of designing simple chips, or you could see RISC as a way of designing fast chips.

In the story of simple chips, designing a RISC instruction set architecture with its simple and regular set of operations and registers and so on is a great way of designing a simple chip. You don't need complex instruction decoding, you don't need microcode, you don't need all sorts of irregularities in this and that, and so on. You throw out complex instructions that would take significant amount of silicon in favour of simple ones (and anyways, the early RISC studies suggested that those instructions didn't get used much anyways). The result would be good enough and more importantly, you could actually design and build it.

In the story of fast chips, all of the ISA and implementation simplicity was there to let you design a small chip that you could make go fast (and then scale up easily to make it go even faster). CPU cycle time was a holy thing and every instruction and feature had to be usable by the compiler in practice to make things go faster, not just locally (in code where it could be used) but globally (looking at total execution time across all programs, however you did that). Various RISC research had showed you could throw out a lot of the CISC complexity and push a lot of things to the compiler without slowing code down in practice, so that's what you did. Designing one of these RISC chips was actually a pretty big amount of work, not for the raw design so much as also building the compilers, the simulation environment, and so on.

(These RISC chips were almost invariably built in conjunction with their compilers. The chip and the compiler were two parts of a single overall system.)

Almost all of the RISC chips that people like me have heard of (and lusted after) were designed under the fast chips story; this is MIPS, the DEC Alpha, the Sun SPARC, IBM's Power (later PowerPC aka PPC), Intel's Itanium, and HP's PA-RISC, probably among others. This is the sort of RISC that I learned about from John Mashey's comp.arch posts in the late 1980s and early 1990s and what I still reflexively think of as 'RISC' today. They were what went into Unix servers and workstations (and then later into Macs) and the loss of their elegant, nice architectures to the brute force and money of x86 made many Unix people sad.

(I'd say that I've gotten over my own sadness, but that's not quite what I did. I still don't particularly like the x86 architecture, I just ignore it because my machines are cheap and run fast.)

As I discovered when I researched my entry on ARM, ARM chips are the other story, the unsexy story, the story of simple chips. Unix people like me didn't (and often still don't) really pay them much attention because they were never really server or workstation chips; they didn't appear in machines that we really cared about. Of course the punchline is that they turned out to be the more important sort of RISC chips.

Comments on this page:

From at 2013-05-01 01:16:11:

It's a shame that the SPARC T1 and T2 didn't make more of a hit with the design being open source. I know there's a couple FPGA's out there with a T1 design.


From at 2013-05-01 16:59:33:

Itanium was not a RISC. It's a complex ISA that primarily aims at parallel execution, or using the large available gate count for something smarter than enormous cache.

By cks at 2013-05-02 11:37:07:

Although I haven't examined Itanium's ISA in detail, my impression is that it was a VLIW RISC architecture in that the actual instructions were wide but the individual sub-instructions within them were RISCy, and the whole thing had a RISCy approach where it depended very much on compilers instead of in-CPU scheduling and so on.

(Based on some web searches, it also seems that the general impression of Itanium is that it falls into the RISC family.)

By crest at 2023-02-04 17:27:59:

The problem with Itanium was it didn't just rely on "the compiler" instead it relied on the mystical "sufficiently smart compiler" (that never materialised).

Written on 30 April 2013.
« My practical problem with preconfigured virtual machine templates
Two xargs gotchas that you may not know about »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Tue Apr 30 23:00:14 2013
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.