Computer architecture · 1980 · David A. Patterson & David R. Ditzel

The Case for the Reduced Instruction Set Computer

Evaluate instruction-set complexity as a whole hardware-compiler system: more instructions do not automatically produce better cost or performance.

How to read the original

  1. Read Introduction and distinguish total cost-effectiveness from instruction count.
  2. Read Reasons for Increased Complexity and identify which arguments require workload evidence.
  3. Read Conclusion and apply its instruction-selection questions to the toy experiment below.

Evaluate the system, not the vocabulary

Patterson and Ditzel challenge the assumption that a richer instruction set necessarily yields a more cost-effective computer. Their argument joins hardware implementation, compiler behavior, and workload measurement. Read it as a design argument made under particular technology constraints, not a permanent ranking of modern processor brands. An instruction can be valuable on one workload while imposing costs on all implementations that must support it.

Original reconstruction: two machines, one workload

Suppose a benchmark consists of 900 common operations and 100 compound operations. On a simple design, each common operation uses one instruction and each compound operation expands into four. The program therefore executes 900+400=1300 instructions. Assume each instruction costs one cycle and the clock period is one nanosecond. Its modeled execution time is 1300 nanoseconds.

A richer design supplies one instruction per compound operation. It executes only 1000 instructions. Assume common instructions cost one cycle, compound instructions cost three cycles, and added implementation complexity lengthens the cycle to 1.2 nanoseconds. Its time is (900+100×3)×1.2=1440 nanoseconds. Instruction count improves while execution time worsens.

Now change the workload to 500 common and 500 compound operations. The simple design takes 500+500×4=2500 nanoseconds. The rich design takes (500+500×3)×1.2=2400 nanoseconds and wins. The reversal is the point of the exercise: the conclusion depends on workload frequency and the actual implementation costs, not the number of names in an instruction manual.

Let f be the fraction of compound operations among N source-level operations. Under these invented assumptions, simple time per operation is 1+3f nanoseconds, while rich time is 1.2+2.4f. The rich design wins when 1.2+2.4f<1+3f, or f>1/3. At exactly one third the simplified models tie. This algebra exposes the assumption that a marketing claim would otherwise conceal.

Add the omitted costs deliberately

The example ignores instruction-cache misses, memory stalls, pipeline overlap, code size, and compiler quality. If the four-instruction expansion increases fetch traffic enough to cause extra misses, the simple design loses part of its advantage. If a compiler rarely recognizes the compound idiom, the rich instruction may deliver little benefit despite occupying control and verification resources.

Do not repair the model by adding every possible variable without evidence. Choose a hypothesis, such as instruction-fetch pressure, and measure it on the same verified workload. Record elapsed time, code bytes, dynamic instruction count, and the conditions under which the special instruction is emitted. A benchmark should compare equivalent results and include the cost of required setup and cleanup.

Read historical claims with an engineering notebook

Separate the paper’s evidence from the teaching numbers above. The calculated crossover is not a reported result from the 1980 machines. It is a reusable method for asking which frequency, latency, or cycle-time claim must be measured next. Also distinguish an architectural instruction from the internal operations used to implement it: one visible instruction can still require many internal steps.

A defensible ISA proposal specifies semantics, likely compiler use, implementation impact, and the cost of supporting the feature across future designs. Simplicity can make a common path easier to optimize, but simplicity is not itself a unit of performance. The lasting skill is to find the denominator of a claimed improvement and test whether the whole program benefits.

Reconstruction exercise

Keep the lesson’s implementation costs, but use 800 common and 200 compound operations. Calculate both runtimes. Then suppose the richer design’s clock period improves from 1.2 to 1.1 nanoseconds without changing cycle counts. Recalculate and explain why this change cannot be assumed free in a real design review.

Worked solution

The simple design executes 800+200×4=1600 one-nanosecond cycles, so its modeled time is 1600 ns. The rich design executes 800+200×3=1400 cycles. At 1.2 ns each, it takes 1680 ns and is slower despite issuing fewer instructions. At 1.1 ns, the same cycle count takes 1540 ns and becomes faster. The revised clock changes an implementation parameter on which the conclusion depends. Achieving it could require a different circuit, extra area, more power, additional pipeline stages, or a changed technology process. A comparison must state whether those costs are within the design budget and whether the same improvement could also benefit the simple machine. Furthermore, the cycle model excludes memory and fetching effects. Measure complete workload behavior before generalizing the arithmetic to a commercial processor.

Test the limits and transfer the idea

1. Performance model · allow 40 minutes

Find the compiler recognition threshold

Extend the reading's invented machine model. Forty percent of source operations are compound. A simple machine expands each compound operation into four one-cycle instructions and uses a 1 ns cycle. The richer machine uses a 1.2 ns cycle; a recognized compound operation uses one three-cycle instruction, while an unrecognized one still expands to four one-cycle instructions. Common operations use one cycle on either machine. Let r be the fraction of compound operations recognized by the richer machine's compiler.

Derive runtime per source operation as a function of r, find the threshold for the richer design to win, and evaluate r=0.8 and r=1. Then explain how to measure r without confusing static source patterns with dynamic execution frequency. Name two omitted costs that could reverse the result.

Get a starting hint

Count unrecognized compound work as four cycles, not one. The slower clock applies to all instructions.

Compare your reasoning with the worked solution

The simple machine uses 0.6×1+0.4×4=2.2 cycles per source operation, giving 2.2 ns. On the richer machine, recognized and unrecognized compounds contribute 0.4[3r+4(1-r)] cycles, so total cycles are 2.2-0.4r. Multiplying by 1.2 ns gives T_rich=2.64-0.48r ns.

To beat 2.2 ns requires 0.48r>0.44, or r>11/12, approximately 91.67%. At r=0.8 the time is 2.256 ns, about 2.55% slower than the simple design. At r=1 it is 2.16 ns, about 1.82% faster. The small advantage leaves little room for unmodeled costs. At the threshold the machines tie; recognizing a majority of patterns is insufficient under these particular costs.

Measure dynamically executed eligible compound operations and the subset actually implemented with the specialized instruction on the same input and verified result. Counting patterns in a source file gives each occurrence equal weight even if one sits in a loop executed a million times. Disassembly establishes code generation but needs execution counts to establish r. Include legal recognition constraints such as overflow, aliasing, or exceptional behavior: replacing a pattern is allowed only when semantics match.

Instruction-fetch misses, data-memory stalls, compiler register spills, and any setup needed by the compound instruction are omitted. So are hardware area and energy. The arithmetic is a sensitivity analysis motivated by the paper's joint compiler/hardware argument, not evidence that any historical or current ISA has this crossover.

Check your reasoning

  • Derives 2.64-0.48r and the strict 11/12 threshold.
  • Calculates both test cases with consistent denominators.
  • Defines dynamic recognition measurement and semantic constraints.

2. Measurement and counterexample · allow 35 minutes

Expose the workload behind an average speedup

Two benchmark tasks A and B each take 100 ms on a simple design. On a richer design A takes 50 ms and B takes 200 ms. Results are correct and timings include all work. A report averages the per-task simple/rich speedup ratios and advertises a 25% speedup.

Calculate that average, the geometric mean of the two speedup ratios, and elapsed time for a batch containing one of each. Then evaluate deployment mixes of nine A plus one B and one A plus nine B. Explain what must be specified before averaging measurements can support an architectural decision. Connect the result to the paper's argument about cost-effectiveness without declaring either instruction-set philosophy universally superior.

Get a starting hint

Ratios and elapsed times are different quantities. A workload executes tasks, not an arithmetic mean of speedup ratios.

Compare your reasoning with the worked solution

The ratios are 100/50=2 and 100/200=0.5. Their arithmetic mean is 1.25, the advertised number. Their geometric mean is sqrt(2×0.5)=1. But one A plus one B takes 200 ms on the simple machine and 250 ms on the richer one, giving batch speedup 200/250=0.8. The richer batch is 25% slower in elapsed time. Thus an average ratio of 1.25 does not establish a 25% reduction in time, even for the equal-count mix.

For nine A and one B, the simple time is 1000 ms and the richer time is 9×50+200=650 ms. The batch speedup is about 1.538, a 35% time reduction. For one A and nine B, the richer time is 50+9×200=1850 ms, giving speedup about 0.541 and an 85% time increase. Workload composition reverses the decision.

State whether weights represent task counts, baseline CPU time, user populations, or service value. A geometric mean can summarize multiplicative ratios with useful symmetry, but it is not a substitute for total time of a specified task mixture. Also define measurement variability, input sizes, compiler settings, and whether latency, throughput, cost, or energy is the objective. Patterson and Ditzel's design question concerns the complete system and its workloads. This original counterexample shows why a favorable summary statistic cannot settle that question without its denominator and workload interpretation.

Check your reasoning

  • Computes ratio averages and all three batch totals.
  • Distinguishes speedup from percentage time reduction.
  • Specifies meaningful weights and limits the architectural inference.

Check your understanding

Under the reading’s model, which compound-operation fraction makes the richer design faster?

  • Every positive fraction.
  • Only fractions above one third.
  • Only fractions below one tenth.
  • No fraction can do so.
Explanation

Comparing the modeled times 1.2 + 2.4f and 1 + 3f gives f > 1/3. At exactly one third they tie; a higher fraction favors the richer design under these assumptions.

A new instruction halves dynamic instruction count. What further evidence is needed?

  • Only the frequency of the new instruction, without timing it.
  • Only the worst-case instruction latency, regardless of frequency.
  • Only the static executable size.
  • Execution costs, clock behavior, and whole-workload measurements.
Explanation

Instruction count is one factor in execution time and omits other implementation costs.

Original paper and sources

David A. Patterson and David R. Ditzel. The Case for the Reduced Instruction Set Computer. ACM SIGARCH Computer Architecture News, 1980.

Read the original paper →

Read the primary paper: University of Texas at Austin