There is a whole lotta truth in the old acronym KISS. "Keep It Simple Stupid" has centuries of cultural research to back it up, but sometimes the obvious escapes even the best of us. Look at the debate over the last couple of years about RISC vs. CISC. For those of you who have been on vacation for the last five years or so, RISC stands for Reduced Instruction Set Computer and CISC for Complex Instruction Set Computer. It is commonly held that CISC is the older technology and RISC the newer, and that RISC is somehow technologically superior. These are actually marketing positions thrust on us by the manufactures that currently build RISC based platforms, not intrinsic truths. The debate has become an emotional one and emotional arguments cannot be won -- its sort of like the commercial, "tastes great" vs. "less filling".

The truth is RISC and CISC are opposite ends of a pendulum that has been swinging back and forth for some time. The earliest computers had very simple instructions sets. The only reason they were not RISC is you seem to need something complicated before you can "reduce" it. The original Pick machines such as the Microdata and Ultimate Honeywell DPS 6 (and big machines like the IBM 360/370 series) were all what's known as firmware machines. That simply means they had a very simple basic instruction set (the firmware instructions) and many of these simple instructions were combined into more complex and useful instructions (the target instruction set). Thus, they had elements of both RISC and CISC simultaneously!

Thinking back to the start of the Intel dynasty, the 4004 (predecessor to the 8080 and 80X86 series) had a very simple instruction set. Then microprocessors began to get more and more complicated -- more addressing modes, more instructions, more options. This caused the transistor count and the size of the die (chip) to increase dramatically. This newly enriched architecture was a boon to assembly language programmers, but had some negative side effects. The raw size of the chips and the complexity of decoding all the instruction options caused the chips to run slower (more clocks per instruction). This effected not just the complex instructions, but often many of the simpler ones as well. The overall complexity also dramatically increased the development time and effort -- to the point where some major chip manufacturers had serious slippage's in delivery schedules.

Next someone got a bright idea. Perhaps "rediscovered" is a better way to phrase it because this idea is at the heart of all performance improvement, at nearly all levels of life. I have written about it several times -- focus on what's important.
For microprocessors this comes down to finding out what instructions are actually used. When the researchers actually analyzed the executed instruction streams, they discovered some interesting, but not necessarily surprising, information. While the assembly programmers thought these new instructions were great, most of the world programs in high level languages, and the compilers for these languages were not using the complex instructions. In fact 80 or 90 percent of the instructions executed in the real world were only about 20 percent of the instruction set (the famous 80/20 rule!) So human nature being what it is, the great herd charged off en masse to create Reduced Instruction Set Computers.

Simplifying the instruction design increased the size of the average instruction so that instruction decoding was easier and allowed many instructions to be executed in one base clock cycle. A smaller chip area also allowed the clock rates to be increased. These early generation RISC chips still had many slow instructions that caused either a slower overall clock rate or kept the complexity high. The solution was to use some additional chip space to setup some fairly complex parallel processing stages. Instruction fetch, address decode, data fetch, CPU operations, and data write-back are done in one clock each at separate stages. Thus for most current RISC chips, the one clock per instruction rule is not even close to being technically correct. Each instruction actually takes five or more clocks, but because there are many instructions executing simultaneously, much of the time the instruction appears to execute in one clock.

The side effects of these changes created their own problems. Higher clock rates and larger instructions caused the chip to use much more bus bandwidth for instruction fetches. This is aggravated by the tendency to pre-fetch instructions that won't actually get executed and failed jump path prediction (this is where the chip starts fetching and executing instructions before it is sure it's on the correct leg of a conditional branch). This higher bus utilization caused bottlenecks for multiprocessor RISC implementations and large I/O loads that needed more bus than was available. Designers then had to increase bus speeds, add bigger on-chip caches and more on-chip registers to counter these problems.

By now, RISC chips have grown back to nearly the physical size of CISC chips. Meanwhile, CISC designers have been making their own improvements and in some applications are providing very comparable performance. In fact, some of the more successful "RISC" chips such as the Hewlett Packard Precision Architecture (HP PA) chip has so many added functions that it is really not a true RISC chip, but a high performance hybrid, and some of the hottest chips around such as the Pentium are still CISC designs. Having by now lost all but my most technical audience, what is my point?

Good thing you asked! The point is both architecture's have merit and while the pendulum swings back and forth, it spends most of its time somewhere in the middle. In other words, you shouldn't by a computer because its RISC or CISC, but rather because it performs the job you need done better than your other choices. Better often means faster, but could mean a lot of other things as well -- price, expandability, fault-tolerance, vendor reliability or support or openness, and communications or peripheral options are just a few that come to mind. Even the issue of speed is complicated by your application. If you want performance at your user's terminals, be sure that's where you measure it and not in a marketing brochure that stresses RISC or clock rates. Keep it simple stupid -- what does this product do for your application performance, your users, and your company?

Next month I'll be exploring whether there is a RISC vs. CISC concept to be applied to the rest of your data processing organization (or does a simple KISS work at the office anymore?).