Instruction Sets and Beyond

1
Instruction Sets and Beyond

• Computers, Complexity, and Controversy
• Brian Blum, Darren Drewry
• Ben Hocking, Gus Scheidt

2
Outline

• Points of Clarification
• RISC and CISC defined
• Points of Attention and Contention
• RISC II and the MCF Evaluation
• Multiple Register Sets
• The 432
• Summary

3
Points of Clarification

• 1985 - What is RISC today?
• RISC Number of Instructions
• RISCacademic .vs. CISCcommercial

4
RISC Defined

• Single Cycle Operation
• Load / Store Design
• Hardwired Control (No microcode)
• Few Instructions and Addressing Modes
• Fixed Instruction Format
• More Compile Time Effort
• (Split Data and Instruction Cache)

5
CISC in Comparison

• Larger and more Complex (Insn Addr)
• Multiple Cycle Execution (micro-instructions)
• Upward Compatible (w/ Obsolete Insn)
• Standardized
• More Hardware (on-chip logic)
• Fewer Registers Unified Cache?

6
RISC and CISC General Points

• CISC Built for Language (Assembly)
• CISC Built for Memory Conservation
• CISC Focuses on Standards and Compatibility
• RISC Designed for Speed
• RISC Simultaneous Access to Code and Operands
• RISC Reliance on Compilers
• Worse or just Different?

7
Two Misconceptions about RISC and CISC

• Implication that discussion is limited to
  selection of instruction set.
• Tradeoffs across various boundaries
• architecture / implementation
• hardware / software
• compile-time / run-time

8
Two Misconceptions about RISC and CISC

• Implication that any machine is one or the other.
• Machine performance difficult to interpret
• Absolute number of instructions is not the only
  criterion
• - compiler / architecture coupling
• - non-instruction set design
  decisions

9
Early arguments for RISC

• Simpler designs could be realized more quickly
• Avoid performance disadvantages of old
  implementation technology.

10
DECs MicroVAX-32

• Qualifies as a CISC
• Very short development period
• Standardization of instruction set
• RISC can benefit from standardization
• Demonstrates importance of assigning function to
  appropriate implementation level
• Microcoding can be a valuable technique

11
Misleading RISC Claims

• Amount of design time saved.
• Academic vs. commercial design and production
• Performance claims.
• Typical benchmarks avoid metrics of reliability
  and response time
• Use of micro-benchmarks vs. large, heterogeneous
  benchmarks

12
Multiple Register Sets

• Performance feature independent of RISC aspect of
  processor
• Reduce frequency of register saves/restores on
  procedure calls
• Overlap register sets for parameter passing
• MRS impact performance for both RISC and CISC

13
Effect of MRS on CISC
Effect of MRS on RISC
14
RISC II and the MCF Evaluation

• Used by Department of Defense to evaluate
  life-cycle cost of computers
• Efficiency defined as program size memory bus
  traffic canonical processor cycles
• VAX (CISC) judged best by MCF
• RISC II evaluation compared to VAX

15
RISC II and the MCF Evaluation

• Results of comparison
• VAX requires 3.5 times less memory (for program
  instructions)
• RISC II has 2.5 times more processor-memory
  traffic
• VAX requires fewer cycles than RISC II

16
A CISC Example The 432

• Object-oriented
• Geared towards Ada
• Every object protected uniformly
• Variable length instructions (6-321 bits)
• On-chip microcode
• Every memory reference is checked

17
Problems with the 432

• 10-20 times as slow on low-level benchmarks (such
  as Hanoi)
• No on-chip data caching
• No instruction stream literals
• No local registers
• Ada compile performs almost no optimization

18
Advantages of the 432

• Reliability
• Could be faster at more realistic benchmarks
  (especially ones that use IPCs)

19
Lessons from the 432

• Even with all of the oversights of the 432, it
  has an important advantage reliability
• More realistic benchmarks should be used to
  compare RISC with CISC
• CISCs should take advantage of multiple register
  sets

20
Conclusions

• When comparing RISC with CISC you should use
  similar hardware organizations
• Benefits depend on
• Types of programs being run
• Whether requirements are based on
• Performance
• Reliability
• Some other factor or set of factors

21
And now to thank those who made this all possible!