Overview. EE 4504 Computer Organization. This section. Items to be discussed. Section 9 RISC Architectures. Reading: Text, Chapter 12

Transcription

1 Overview EE 4504 Computer Organization Section 9 RISC Architectures This section Explores the development of RISC (Reduced Instruction Set Computer) architectures and Contrasts them with conventional CISC (Complex Instruction Set Computer) designs Items to be discussed HLL language and machine code characteristics that support RISC Implementation of RISC ideas Overview of RISC machines Ongoing debate as to the worth of RISC Reading: Text, Chapter 12 EE 4504 Section 9 1 EE 4504 Section 9 2 1

2 Our author identifies a number of advances in computer architecture over the past 50 years Family concept Microprogramming Cache Pipelines Parallel processing Further, he asserts that RISC architectures are destined to be added to the list Contrast with Meyers (Advances in Computer Architecture, 2d ed., 1981) Most computer architects have based their designs on tradition and the bottom-up view to minimize the cost of hardware and let the programmers solve all of the difficult problems. One way of substantiating this statement is to show that, with a few exceptions, there have been no advances in the computer architectures of current systems since the 1950s....However, such examples do not represent architecture concepts; they are advances in implementation of particular architectures, that is, they are processor architecture or organization advances. EE 4504 Section 9 3 EE 4504 Section 9 4 2

3 The 1970s: setting the stage for RISC Through the 50s, 60s, and 70s, the general trend in computer architecture was that hardware costs were dropping while software costs increased -- software was becoming the major portion of a system s life cycle cost Response was to develop increasing more complex high level languages (HLLs) to aid in the design and maintenance of software Impact was the creation of the semantic gap that we have discussed previously Semantic gap had to be bridged by the compiler To reduce the semantic gap, much effort was spent on raising the sophistication of the hardware itself -- migration of HLL concepts into the instruction set» Ease the task of compiler writing» Improve execution efficiency (complex stuff is in fast microcode)» Support even more complex HLLs Microprocessor development in the late 70s: 8-bit designs out the door 16-bit product just being released Typical chip contained 30-40,000 transistors Much of the chips design, layout, and test was done manually» Labor intensive (with high-paid labor!!)» Slow process In some portions of the research community, there was a genuine fear that computer development would be stymied by chip design limitations Thus began the search for an alternative design approach -- RISC was the outcome EE 4504 Section 9 5 EE 4504 Section 9 6 3

4 Instruction Execution Characteristics A brief history of RISC First publicized RISC effort seems to have been the IBM 801 project in the late 70s and early 80s» Developed a minicomputer based on what came to be known as RISC technology» Named after the building the team worked in at the T J Watson center David Patterson, UC Berkeley» RISC I and RISC II machines» Stressed large register sets» Forerunner of the SPARC architectures John Hennessy, Stanford» MIPS systems» Stressed optimizing compilers and pipelines Hennessy and Patterson wrote a series of papers that defined the RISC movement and set the stage for the ongoing RISC vs. CISC debate Development of RISCs were based on the study of instruction execution properties Operations performed Operations used Execution sequencing Operations EE 4504 Section 9 7 EE 4504 Section 9 8 4

5 Static assessment:» Assignment statements predominate -- simple data movement instructions» Large number of conditional statements Dynamic assessment: which statements in HLL program cause the execution of the most machine language instructions» Results of Table 12.2 suggest that subroutine call statements are the most time-consuming operations in HLL programs Target architectural implementation to support these operations well Operands Preponderance of variables are scalar and local» Interger constant -- 20%» Scalar variable -- 55%» Array value -- 25% (with scalar index)» 80% of scalars local to the routine Optimization should focus on storing and accessing local scalar variables EE 4504 Section 9 9 EE 4504 Section

6 Execution sequencing Subroutine calls are the time-consuming operation in HLLs Minimize their impact by» Streamlining the parameter passing» Efficient access to local variables» Support nested subroutine invocation Statistics» 98% of dynamically called procedures passed fewer than 6 parameters» 92% use less than 6 local scalar variables» Rare to have long sequences of subroutine calls followed by returns (e.g., a recursive sorting algorithm)» Depth of nesting was typically rather low Implications for architecture design Reducing the semantic gap through complex architectures may not be the most efficient use of system hardware Optimize machine design based on the most time-consuming tasks of typical HLL programs Use large numbers of registers» Reduce memory reference by keeping variables close to CPU» Streamlines instruction set by making memory interactions primarily loads and stores Pipeline design» Minimize impact of conditional branches Simplify instruction set rather than make it more complex EE 4504 Section 9 11 EE 4504 Section

7 Large Register Files Large number of assignment operations involving scalar variables suggests a high reliance on register use Support register use in Software» Sophisticated program analysis by the compiler» Predict which variables should be in registers as the program progresses» Basis for the Stanford MIPS machines Hardware» Build more registers» Use hardware to avoid the complexity of compiler optimization» Basis for the Berkeley RISC machines If large numbers (100s) of registers are implemented in the CPU, how should they be used? Execution sequencing data suggested that subroutines pass small numbers of parameters and use small numbers of local variables Lots of time spent in subroutine calls and returns Organize large register set into a series of overlapping register windows A subroutine is allocated a new register window upon instantiation Register window being used by the calling routine is preserved -- traditional state saving does not need to be performed Pass parameters by overlapping windows of calling and called routines EE 4504 Section 9 13 EE 4504 Section

8 Parameter registers LVs Window j Call/return overlap LVs Window j+1 Since number of registers and therefore windows is finite, how many register windows are enough 8 windows seen to handle all but 1% of calls and returns For the 1%, push window contents into memory to make room for the new call Window j+2 LVs Overlapping register windows for 3 nested subroutines EE 4504 Section 9 15 Figure 12.2 Circular buffer configuration of windows EE 4504 Section

9 Compiler Optimization Global variables??? Store in memory and interact with memory read and write operations Allocate some portion of registers as global that all subroutines can access» Registers 0-7 all global» Registers 8-31 are local to a particular window Why not just build a big cache? Answer not clear cut Window holds all local scalars Cache holds selection of recently used data Cache can be forced to hold data it never uses (due to block transfers) Current data in cache can be swapped out due to accessing scheme used Cache can easily store global and local variables Addressing registers is cleaner and faster In this case, the number of registers is small compared to the large register file implementation The compiler is responsible for managing the use of the registers Compiler must map the current and projected use of variables onto the available registers Similar to a graph coloring problem Form a graph with variables as nodes and edges that link variables that are active at the same time Color the graph with as many colors as you have registers Variables not colored must be stored in memory EE 4504 Section 9 17 EE 4504 Section

10 Evaluation of compiler-based optimization shows that even simple register optimization can reduce the need for large register sets. Little use for more than 64 registers With better optimization (better compiler) only marginal performance improvement using more than 32 registers Figure 12.4 Register allocation using graph coloring EE 4504 Section 9 19 EE 4504 Section

11 RISC Definition RISC vs. CISC What does a RISC architecture entail? Our author: Limited and simple instruction set Large number of GP registers or the use of compiler technology to optimize register use Emphasis on optimizing the instruction pipeline Colwell et. al: Single cycle operation Load / store design Hardwired control Relatively few instructions and addressing modes Fixed instruction formats More compile-time effort RISC vs. CISC controversy has gone on for the past 15 years Good level playing field papers Instruction sets and beyond: computers, complexity, and controversy, Colwell et. al., IEEE Computer, September Counter arguments and rebuttals in September and December issues. And now a case for more complex instruction sets, Flynn et. al., IEEE Computer, September Interesting current exchange in The RISC penalty, Pittman, IEEE Micro, December Counter arguments and rebuttals in the February 1996 issue. EE 4504 Section 9 21 EE 4504 Section

12 In fact, there seems to be a blending of features -- RISCS that include CISC attributes and vice versa From Colwell: There are 2 prevalent misconceptions about RISC and CISC. Claims concerning decreased design time Meaningful performance metrics From Flynn: Level playing field From Pittman RISC... commitment is foolish At the same time the designers simplify the instruction set, they add a whole bunch of other improvements, and the aggregate is called RISC Hand optimization From Burgess:...real issue is cacheability Balanced optimization EE 4504 Section 9 23 EE 4504 Section