................................................................................................................................................................ Common Bonds: MIPS, HPS, Two-Level Branch Prediction, and Compressed Code RISC Processor ONUR MUTLU ETH Zurich RICH BELGARD ......We are continuing our series of retrospectives for the 10 papers that received the first set of MICRO Test of Time (“ToT”) Awards in December 2014. 1,2 This issue features four retro- spectives written for six of the award- winning papers. We briefly introduce these papers and retrospectives and hope that you will enjoy reading them as much as we have. If anything ties these works together, it is the innovation they delivered by taking a strong position in the RISC/CISC debates of their decade. We hope the IEEE Micro audience, espe- cially younger generations, will find the historical perspective provided by these retrospectives invaluable. MIPS The first retrospective is for the oldest paper being discussed in this issue: “MIPS: A Microprocessor Architecture.” 3 This work introduced MIPS (Microproces- sor without Interlocked Pipeline Stages) and its design philosophy, principles, hard- ware implementation, related systems, and software issues. It is a concise over- view of the MIPS design, which is one of the early reduced, or simple, instruction sets that have significantly impacted the microprocessor industry as well as com- puter architecture research and education for decades (and probably counting!). The key design principle is to push the burden of performance optimization on the com- piler and keep the hardware design sim- ple. The compiler is responsible for generating and scheduling simple instruc- tions, which require little translation in hardware to generate control signals to control the datapath components, which in turn keeps the hardware design simple. Thus, the instructions and hardware both remain simple, whereas the compiler becomes much more important (and likely complex) because it must schedule instructions well to ensure correct and high-performance use of a simple pipe- line. Many modern processors continue to take advantage of some of the design principles outlined in this paper, either in their ISA (the MIPS ISA still has consider- able use) or in their internal execution of instructions (many complex instructions are broken into simple RISC-style microin- structions in modern processors). The MIPS ISA and design is also used in many modern computer architecture courses because of its simplicity. Thomas Gross, Norman Jouppi, John Hennessy, Steven Przybylski, and Chris Rowen provide in their retrospective a historical perspective on the development of MIPS, the context in which they arrived at the design principles, and the develop- ments that occurred after the paper. They also provide their reflections on what they see as the design and evaluation deci- sions made in the MIPS project that passed the test of time. The retrospective touches on the design tradeoffs made to couple the hardware and the software, the MIPS project’s effect on the later development of “fabless” semiconductor companies, and the use of benchmarks as a method for evaluating end-to-end performance of a system as, among others, contributions of the MIPS project that have stood the test of time. High-Performance Systems The second retrospective addresses three related papers that received MICRO ToT Awards in 2014. These papers introduce the High Performance Substrate (HPS) microarchitecture, examine its critical design issues, and discuss the use of large hardware-supported atomic units to enhance performance in HPS-style, dynam- ically scheduled microarchitectures. The first paper, “HPS, A New Micro- architecture: Rationale and Introduction,” 4 introduced the HPS microarchitecture, its design principles, and a prototype imple- mentation. It also introduced the concept of restricted dataflow and its use in imple- menting out-of-order instruction schedul- ing and execution while maintaining sequential execution and precise excep- tions from the programmer’s perspective (that is, without exposing the out-of-order- ness of dataflow execution to software). ....................................................... 70 Published by the IEEE Computer Society 0272-1732/16/$33.00  c 2016 IEEE Awards