Computer Architecture Carnegie Mellon University

Slides:



Advertisements
Similar presentations
Lecture 4: CPU Performance
Advertisements

1 Pipelining Part 2 CS Data Hazards Data hazards occur when the pipeline changes the order of read/write accesses to operands that differs from.
Mehmet Can Vuran, Instructor University of Nebraska-Lincoln Acknowledgement: Overheads adapted from those provided by the authors of the textbook.
Pipeline Computer Organization II 1 Hazards Situations that prevent starting the next instruction in the next cycle Structural hazards – A required resource.
1 Seoul National University Wrap-Up. 2 Overview Seoul National University Wrap-Up of PIPE Design  Exception conditions  Performance analysis Modern.
Spring 2003CSE P5481 Reorder Buffer Implementation (Pentium Pro) Hardware data structures retirement register file (RRF) (~ IBM 360/91 physical registers)
Chapter 8. Pipelining. Instruction Hazards Overview Whenever the stream of instructions supplied by the instruction fetch unit is interrupted, the pipeline.
Chapter 12 CPU Structure and Function. CPU Sequence Fetch instructions Interpret instructions Fetch data Process data Write data.
Computer Organization and Architecture
– 1 – Chapter 4 Processor Architecture Pipelined Implementation Chapter 4 Processor Architecture Pipelined Implementation Instructor: Dr. Hyunyoung Lee.
1 IF IDEX MEM L.D F4,0(R2) MUL.D F0, F4, F6 ADD.D F2, F0, F8 L.D F2, 0(R2) WB IF IDM1 MEM WBM2M3M4M5M6M7 stall.
PipelinedImplementation Part I CSC 333. – 2 – Overview General Principles of Pipelining Goal Difficulties Creating a Pipelined Y86 Processor Rearranging.
Chapter 12 Pipelining Strategies Performance Hazards.
Wrap-Up CSC 333. – 2 – Overview Wrap-Up of PIPE Design Performance analysis Fetch stage design Exceptional conditions Modern High-Performance Processors.
7/2/ _23 1 Pipelining ECE-445 Computer Organization Dr. Ron Hayne Electrical and Computer Engineering.
Appendix A Pipelining: Basic and Intermediate Concepts
Pipelining. Overview Pipelining is widely used in modern processors. Pipelining improves system performance in terms of throughput. Pipelined organization.
Group 5 Alain J. Percial Paula A. Ortiz Francis X. Ruiz.
Pipelining III Topics Hazard mitigation through pipeline forwarding Hardware support for forwarding Forwarding to mitigate control (branch) hazards Systems.
David O’Hallaron Carnegie Mellon University Processor Architecture PIPE: Pipelined Implementation Part I Processor Architecture PIPE: Pipelined Implementation.
Ch2. Instruction-Level Parallelism & Its Exploitation 2. Dynamic Scheduling ECE562/468 Advanced Computer Architecture Prof. Honggang Wang ECE Department.
Data Hazard Solution 2: Data Forwarding Our naïve pipeline would experience many data stalls  Register isn’t written until completion of write-back stage.
Lecture 15: Pipelining and Hazards CS 2011 Fall 2014, Dr. Rozier.
Edited By Miss Sarwat Iqbal (FUUAST) Last updated:21/1/13
1 Seoul National University Pipelined Implementation : Part I.
CS.305 Computer Architecture Enhancing Performance with Pipelining Adapted from Computer Organization and Design, Patterson & Hennessy, © 2005, and from.
Computer Architecture: Wrap-up CENG331 - Computer Organization Instructors: Murat Manguoglu(Section 1) Erol Sahin (Section 2 & 3) Adapted from slides of.
Pipeline Architecture I Slides from: Bryant & O’ Hallaron
PipelinedImplementation Part II PipelinedImplementation.
Superscalar - summary Superscalar machines have multiple functional units (FUs) eg 2 x integer ALU, 1 x FPU, 1 x branch, 1 x load/store Requires complex.
Implementing Precise Interrupts in Pipelined Processors James E. Smith Andrew R.Pleszkun Presented By: Shrikant G.
Adapted from Computer Organization and Design, Patterson & Hennessy, UCB ECE232: Hardware Organization and Design Part 13: Branch prediction (Chapter 4/6)
COMPSYS 304 Computer Architecture Speculation & Branching Morning visitors - Paradise Bay, Bay of Islands.
1 SEQ CPU Implementation. 2 Outline SEQ Implementation Suggested Reading 4.3.1,
Randal E. Bryant Carnegie Mellon University CS:APP2e CS:APP Chapter 4 Computer Architecture PipelinedImplementation Part II CS:APP Chapter 4 Computer Architecture.
Real-World Pipelines Idea –Divide process into independent stages –Move objects through stages in sequence –At any given times, multiple objects being.
1 Pipelined Implementation. 2 Outline Handle Control Hazard Handle Exception Performance Analysis Suggested Reading 4.5.
Pipelining: Implementation CPSC 252 Computer Organization Ellen Walker, Hiram College.
PipeliningPipelining Computer Architecture (Fall 2006)
Real-World Pipelines Idea Divide process into independent stages
Computer Architecture Chapter (14): Processor Structure and Function
William Stallings Computer Organization and Architecture 8th Edition
Systems I Pipelining IV
Morgan Kaufmann Publishers
Administrivia Midterm to be posted on Tuesday after class
Pipelining: Advanced ILP
Computer Architecture adapted by Jason Fritts then by David Ferry
Morgan Kaufmann Publishers The Processor
Pipelined Implementation : Part I
Seoul National University
Seoul National University
Lecture 8: ILP and Speculation Contd. Chapter 2, Sections 2. 6, 2
Pipelined Implementation : Part II
Systems I Pipelining III
Computer Architecture adapted by Jason Fritts
Systems I Pipelining II
Pipelined Implementation : Part I
Seoul National University
Control unit extension for data hazards
Pipeline Architecture I Slides from: Bryant & O’ Hallaron
Pipelined Implementation : Part I
Pipelined Implementation
Control unit extension for data hazards
Systems I Pipelining II
Systems I Pipelining II
Control unit extension for data hazards
Real-World Pipelines: Car Washes
Presentation transcript:

Computer Architecture Carnegie Mellon University CS:APP Chapter 4 Computer Architecture Wrap-Up Randal E. Bryant Carnegie Mellon University http://csapp.cs.cmu.edu CS:APP2e

Overview Wrap-Up of PIPE Design Modern High-Performance Processors Exceptional conditions Performance analysis Fetch stage design Modern High-Performance Processors Out-of-order execution

Exceptions Causes Typical Desired Action Our Implementation Conditions under which processor cannot continue normal operation Causes Halt instruction (Current) Bad address for instruction or data (Previous) Invalid instruction (Previous) Typical Desired Action Complete some instructions Either current or previous (depends on exception type) Discard others Call exception handler Like an unexpected procedure call Our Implementation Halt when instruction causes exception

Exception Examples Detect in Fetch Stage Detect in Memory Stage jmp $-1 # Invalid jump target .byte 0xFF # Invalid instruction code halt # Halt instruction Detect in Memory Stage irmovl $100,%eax rmmovl %eax,0x10000(%eax) # invalid address

Exceptions in Pipeline Processor #1 # demo-exc1.ys irmovl $100,%eax rmmovl %eax,0x10000(%eax) # Invalid address nop .byte 0xFF # Invalid instruction code 1 2 3 4 W 5 M E D Exception detected 0x000: irmovl $100,%eax F D E M 0x006: rmmovl %eax,0x1000(%eax) F D E 0x00c: nop F D 0x00d: .byte 0xFF F Exception detected Desired Behavior rmmovl should cause exception Following instructions should have no effect on processor state

Exceptions in Pipeline Processor #2 # demo-exc2.ys 0x000: xorl %eax,%eax # Set condition codes 0x002: jne t # Not taken 0x007: irmovl $1,%eax 0x00d: irmovl $2,%edx 0x013: halt 0x014: t: .byte 0xFF # Target 1 2 3 4 M E F D W 5 M D F E E D M 6 M E W 7 W M 8 W 9 0x000: xorl %eax,%eax F D E 0x002: jne t F D 0x014: t: .byte 0xFF F Exception detected 0x???: (I’m lost!) 0x007: irmovl $1,%eax Desired Behavior No exception should occur

Maintaining Exception Ordering W icode valE valM dstE dstM stat M Cnd icode valE valA dstE dstM stat E icode ifun valC valA valB dstE dstM srcA srcB stat D rB valC valP icode ifun rA stat F predPC Add status field to pipeline registers Fetch stage sets to either “AOK,” “ADR” (when bad fetch address), “HLT” (halt instruction) or “INS” (illegal instruction) Decode & execute pass values through Memory either passes through or sets to “ADR” Exception triggered only when instruction hits write back

Exception Handling Logic Fetch Stage Memory Stage Writeback Stage dmem_error # Determine status code for fetched instruction int f_stat = [ imem_error: SADR; !instr_valid : SINS; f_icode == IHALT : SHLT; 1 : SAOK; ]; # Update the status int m_stat = [ dmem_error : SADR; 1 : M_stat; ]; int Stat = [ # SBUB in earlier stages indicates bubble W_stat == SBUB : SAOK; 1 : W_stat; ];

Side Effects in Pipeline Processor # demo-exc3.ys irmovl $100,%eax rmmovl %eax,0x10000(%eax) # invalid address addl %eax,%eax # Sets condition codes 1 2 3 4 W 5 M E Exception detected 0x000: irmovl $100,%eax F D E M 0x006: rmmovl %eax,0x1000(%eax) F D E 0x00c: addl %eax,%eax F D Condition code set Desired Behavior rmmovl should cause exception No following instruction should have any effect

Avoiding Side Effects Presence of Exception Should Disable State Update Invalid instructions are converted to pipeline bubbles Except have stat indicating exception status Data memory will not write to invalid address Prevent invalid update of condition codes Detect exception in memory stage Disable condition code setting in execute Must happen in same clock cycle Handling exception in final stages When detect exception in memory stage Start injecting bubbles into memory stage on next cycle When detect exception in write-back stage Stall excepting instruction Included in HCL code

Control Logic for State Changes Setting Condition Codes Stage Control Also controls updating of memory # Should the condition codes be updated? bool set_cc = E_icode == IOPL && # State changes only during normal operation !m_stat in { SADR, SINS, SHLT } && !W_stat in { SADR, SINS, SHLT }; # Start injecting bubbles as soon as exception passes through memory stage bool M_bubble = m_stat in { SADR, SINS, SHLT } || W_stat in { SADR, SINS, SHLT }; # Stall pipeline register W when exception encountered bool W_stall = W_stat in { SADR, SINS, SHLT };

Rest of Real-Life Exception Handling Call Exception Handler Push PC onto stack Either PC of faulting instruction or of next instruction Usually pass through pipeline along with exception status Jump to handler address Usually fixed address Defined as part of ISA Implementation Haven’t tried it yet!

Performance Metrics Clock rate Rate at which instructions executed Measured in Gigahertz Function of stage partitioning and circuit design Keep amount of work per stage small Rate at which instructions executed CPI: cycles per instruction On average, how many clock cycles does each instruction require? Function of pipeline design and benchmark programs E.g., how frequently are branches mispredicted?

CPI = C/I = (I+B)/I = 1.0 + B/I CPI for PIPE CPI  1.0 Fetch instruction each clock cycle Effectively process new instruction almost every cycle Although each individual instruction has latency of 5 cycles CPI > 1.0 Sometimes must stall or cancel branches Computing CPI C clock cycles I instructions executed to completion B bubbles injected (C = I + B) CPI = C/I = (I+B)/I = 1.0 + B/I Factor B/I represents average penalty due to bubbles

CPI for PIPE (Cont.) B/I = LP + MP + RP LP: Penalty due to load/use hazard stalling Fraction of instructions that are loads 0.25 Fraction of load instructions requiring stall 0.20 Number of bubbles injected each time 1  LP = 0.25 * 0.20 * 1 = 0.05 MP: Penalty due to mispredicted branches Fraction of instructions that are cond. jumps 0.20 Fraction of cond. jumps mispredicted 0.40 Number of bubbles injected each time 2  MP = 0.20 * 0.40 * 2 = 0.16 RP: Penalty due to ret instructions Fraction of instructions that are returns 0.02 Number of bubbles injected each time 3  RP = 0.02 * 3 = 0.06 Net effect of penalties 0.05 + 0.16 + 0.06 = 0.27  CPI = 1.27 (Not bad!) Typical Values

Fetch Logic Revisited During Fetch Cycle Timing Select PC Read bytes from instruction memory Examine icode to determine instruction length Increment PC Timing Steps 2 & 4 require significant amount of time

need_regids, need_valC Standard Fetch Timing need_regids, need_valC Select PC Mem. Read Increment 1 clock cycle Must Perform Everything in Sequence Can’t compute incremented PC until know how much to increment it by

A Fast PC Increment Circuit incrPC High-order 29 bits Low-order 3 bits carry MUX 1 Slow Fast 29-bit incre- menter 3-bit adder need_regids High-order 29 bits need_ValC Low-order 3 bits PC

need_regids, need_valC Modified Fetch Timing need_regids, need_valC 3-bit add Select PC Mem. Read MUX Incrementer Standard cycle 1 clock cycle 29-Bit Incrementer Acts as soon as PC selected Output not needed until final MUX Works in parallel with memory read

More Realistic Fetch Logic Fetch Box Integrated into instruction cache Fetches entire cache block (16 or 32 bytes) Selects current instruction from current block Works ahead to fetch next block As reaches end of current block At branch target

Modern CPU Design

Instruction Control Grabs Instruction Bytes From Memory Based on Current PC + Predicted Targets for Predicted Branches Hardware dynamically guesses whether branches taken/not taken and (possibly) branch target Translates Instructions Into Operations Primitive steps required to perform instruction Typical instruction requires 1–3 operations Converts Register References Into Tags Abstract identifier linking destination of one operation with sources of later operations

Execution Unit Multiple functional units Integer/ Branch FP Add Mult /Div Load Store Data Cache Prediction OK? Addr . General Integer Operation Results Register Updates Operations Multiple functional units Each can operate in independently Operations performed as soon as operands available Not necessarily in program order Within limits of functional units Control logic Ensures behavior equivalent to sequential program execution

CPU Capabilities of Intel iCore7 Multiple Instructions Can Execute in Parallel 1 load 1 store 1 FP multiplication or division 1 FP addition > 1 integer operation Some Instructions Take > 1 Cycle, but Can be Pipelined Instruction Latency Cycles/Issue Load / Store 3 1 Integer Multiply 3 1 Integer Divide 11—21 5—13 Double/Single FP Multiply 4 1 Double/Single FP Add 3 1 Double/Single FP Divide 10—15 6—11

iCore Operation Translates instructions dynamically into “Uops” ~118 bits wide Holds operation, two sources, and destination Executes Uops with “Out of Order” engine Uop executed when Operands available Functional unit available Execution controlled by “Reservation Stations” Keeps track of data dependencies between uops Allocates resources

High-Perforamnce Branch Prediction Critical to Performance Typically 11–15 cycle penalty for misprediction Branch Target Buffer 512 entries 4 bits of history Adaptive algorithm Can recognize repeated patterns, e.g., alternating taken–not taken Handling BTB misses Detect in ~cycle 6 Predict taken for negative offset, not taken for positive Loops vs. conditionals

Example Branch Prediction Branch History Encode information about prior history of branch instructions Predict whether or not branch will be taken State Machine Each time branch taken, transition to right When not taken, transition to left Predict branch taken when in state Yes! or Yes? T Yes! Yes? No? No! NT

Processor Summary Design Technique Operation Enhancing Performance Create uniform framework for all instructions Want to share hardware among instructions Connect standard logic blocks with bits of control logic Operation State held in memories and clocked registers Computation done by combinational logic Clocking of registers/memories sufficient to control overall behavior Enhancing Performance Pipelining increases throughput and improves resource utilization Must make sure to maintain ISA behavior