advanced computer architecture l.
Download
Skip this Video
Download Presentation
Advanced Computer Architecture

Loading in 2 Seconds...

play fullscreen
1 / 108

Advanced Computer Architecture - PowerPoint PPT Presentation


  • 185 Views
  • Uploaded on

Advanced Computer Architecture. Chapter 4 Advanced Pipelining Ioannis Papaefstathiou CS 590.25 Easter 2003 (thanks to Hennesy & Patterson). Chapter Overview. 4.1 Instruction Level Parallelism: Concepts and Challenges 4.2 Overcoming Data Hazards with Dynamic Scheduling

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Advanced Computer Architecture' - janeeva


Download Now An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
advanced computer architecture

Advanced Computer Architecture

Chapter 4

Advanced Pipelining

Ioannis Papaefstathiou

CS 590.25

Easter 2003

(thanks to Hennesy & Patterson)

chapter overview
Chapter Overview

4.1 Instruction Level Parallelism: Concepts and Challenges

4.2 Overcoming Data Hazards with Dynamic Scheduling

4.3 Reducing Branch Penalties with Dynamic Hardware Prediction

4.4 Taking Advantage of More ILP with Multiple Issue

4.5 Compiler Support for Exploiting ILP

4.6 Hardware Support for Extracting more Parallelism

4.7 Studies of ILP

Chap. 4 - Pipelining II

chapter overview3
Chapter Overview

Chap. 4 - Pipelining II

instruction level parallelism
Instruction Level Parallelism
  • ILP is the principle that there are many instructions in code that don’t depend on each other. That means it’s possible to execute those instructions in parallel.
  • This is easier said than done:
  • Issues include:
  • Building compilers to analyze the code,
  • Building hardware to be even smarter than that code.
  • This section looks at some of the problems to be solved.

4.1 Instruction Level Parallelism: Concepts and Challenges

4.2 Overcoming Data Hazards with Dynamic Scheduling

4.3 Reducing Branch Penalties with Dynamic Hardware Prediction

4.4 Taking Advantage of More ILP with Multiple Issue

4.5 Compiler Support for Exploiting ILP

4.6 Hardware Support for Extracting more Parallelism

4.7 Studies of ILP

Chap. 4 - Pipelining II

terminology

Instruction Level Parallelism

Pipeline Scheduling and Loop Unrolling

Terminology

Basic Block - That set of instructions between entry points and between branches. A basic block has only one entry and one exit. Typically this is about 6 instructions long.

Loop Level Parallelism - that parallelism that exists within a loop. Such parallelism can cross loop iterations.

Loop Unrolling - Either the compiler or the hardware is able to exploit the parallelism inherent in the loop.

Chap. 4 - Pipelining II

simple loop and its assembler equivalent

Instruction Level Parallelism

Pipeline Scheduling and Loop Unrolling

Simple Loop and its Assembler Equivalent

for (i=1; i<=1000; i++) x(i) = x(i) + s;

This is a clean and simple example!

Loop: LD F0,0(R1) ;F0=vector element

ADDD F4,F0,F2 ;add scalar from F2

SD 0(R1),F4 ;store result

SUBI R1,R1,8 ;decrement pointer 8bytes (DW)

BNEZ R1,Loop ;branch R1!=zero

NOP ;delayed branch slot

Chap. 4 - Pipelining II

fp loop hazards

Instruction Level Parallelism

Pipeline Scheduling and Loop Unrolling

FP Loop Hazards

Loop: LD F0,0(R1) ;F0=vector element

ADDD F4,F0,F2 ;add scalar in F2

SD 0(R1),F4 ;store result

SUBI R1,R1,8 ;decrement pointer 8B (DW)

BNEZ R1,Loop ;branch R1!=zero

NOP ;delayed branch slot

Instruction Instruction Latency inproducing result using result clock cycles

FP ALU op Another FP ALU op 3

FP ALU op Store double 2

Load double FP ALU op 1

Load double Store double 0

Integer op Integer op 0

Where are the stalls?

Chap. 4 - Pipelining II

fp loop showing stalls

Instruction Level Parallelism

Pipeline Scheduling and Loop Unrolling

FP Loop Showing Stalls

1 Loop: LD F0,0(R1) ;F0=vector element

2 stall

3 ADDD F4,F0,F2 ;add scalar in F2

4 stall

5 stall

6 SD 0(R1),F4 ;store result

7 SUBI R1,R1,8 ;decrement pointer 8Byte (DW)

8 stall

9 BNEZ R1,Loop ;branch R1!=zero

10 stall ;delayed branch slot

10 clocks: Rewrite code to minimize stalls?

Instruction Instruction Latency inproducing result using result clock cycles

FP ALU op Another FP ALU op 3

FP ALU op Store double 2

Load double FP ALU op 1

Load double Store double 0

Integer op Integer op 0

Chap. 4 - Pipelining II

scheduled fp loop minimizing stalls

Instruction Level Parallelism

Pipeline Scheduling and Loop Unrolling

Scheduled FP Loop Minimizing Stalls

1 Loop: LD F0,0(R1)

2 SUBI R1,R1,8

3 ADDD F4,F0,F2

4 stall

5 BNEZ R1,Loop ;delayed branch

6 SD 8(R1),F4;altered when move past SUBI

Now 6 clocks: Now unroll loop 4 times to make faster.

Stall is because SD can’t proceed.

Swap BNEZ and SD by changing address of SD

Instruction Instruction Latency inproducing result using result clock cycles

FP ALU op Another FP ALU op 3

FP ALU op Store double 2

Load double FP ALU op 1

Chap. 4 - Pipelining II

unroll loop four times straightforward way

Instruction Level Parallelism

Pipeline Scheduling and Loop Unrolling

Unroll Loop Four Times (straightforward way)

1 Loop: LD F0,0(R1)

2 stall

3 ADDD F4,F0,F2

4 stall

5 stall

6 SD 0(R1),F4

7 LD F6,-8(R1)

8 stall

9 ADDD F8,F6,F2

10 stall

11 stall

12 SD -8(R1),F8

13 LD F10,-16(R1)

14 stall

15 ADDD F12,F10,F2

16 stall

17 stall

18 SD -16(R1),F12

19 LD F14,-24(R1)

20 stall

21 ADDD F16,F14,F2

22 stall

23 stall

24 SD -24(R1),F16

25 SUBI R1,R1,#32

26 BNEZ R1,LOOP

27 stall

28 NOP

Rewrite loop to minimize stalls.

15 + 4 x (1+2) +1 = 28 clock cycles, or 7 per iteration

Assumes R1 is multiple of 4

Chap. 4 - Pipelining II

unrolled loop that minimizes stalls

Instruction Level Parallelism

Pipeline Scheduling and Loop Unrolling

Unrolled Loop That Minimizes Stalls

1 Loop: LD F0,0(R1)

2 LD F6,-8(R1)

3 LD F10,-16(R1)

4 LD F14,-24(R1)

5 ADDD F4,F0,F2

6 ADDD F8,F6,F2

7 ADDD F12,F10,F2

8 ADDD F16,F14,F2

9 SD 0(R1),F4

10 SD -8(R1),F8

11 SD -16(R1),F12

12 SUBI R1,R1,#32

13 BNEZ R1,LOOP

14 SD 8(R1),F16 ; 8-32 = -24

14 clock cycles, or 3.5 per iteration

What assumptions made when moved code?

  • OK to move store past SUBI even though changes register
  • OK to move loads before stores: get right data?
  • When is it safe for compiler to do such changes?

No Stalls!!

Chap. 4 - Pipelining II

summary of loop unrolling example

Instruction Level Parallelism

Pipeline Scheduling and Loop Unrolling

Summary of Loop Unrolling Example
  • Determine that it was legal to move the SD after the SUBI and BNEZ, and find the amount to adjust the SD offset.
  • Determine that unrolling the loop would be useful by finding that the loop iterations were independent, except for the loop maintenance code.
  • Use different registers to avoid unnecessary constraints that would be forced by using the same registers for different computations.
  • Eliminate the extra tests and branches and adjust the loop maintenance code.
  • Determine that the loads and stores in the unrolled loop can be interchanged by observing that the loads and stores from different iterations are independent. This requires analyzing the memory addresses and finding that they do not refer to the same address.
  • Schedule the code, preserving any dependences needed to yield the same result as the original code.

Chap. 4 - Pipelining II

compiler perspectives on code movement

Instruction Level Parallelism

Dependencies

Compiler Perspectives on Code Movement

Compiler concerned about dependencies in program. Not concerned if a HW hazard depends on a given pipeline.

  • Tries to schedule code to avoid hazards.
  • Looks for Data dependencies (RAW if a hazard for HW)
    • Instruction i produces a result used by instruction j, or
    • Instruction j is data dependent on instruction k, and instruction k is data dependent on instruction i.
  • If dependent, can’t execute in parallel
  • Easy to determine for registers (fixed names)
  • Hard for memory:
    • Does 100(R4) = 20(R6)?
    • From different loop iterations, does 20(R6) = 20(R6)?

Chap. 4 - Pipelining II

compiler perspectives on code movement14

Instruction Level Parallelism

Data Dependencies

Compiler Perspectives on Code Movement

Where are the data dependencies?

1 Loop: LD F0,0(R1)

2 ADDD F4,F0,F2

3 SUBI R1,R1,8

4 BNEZ R1,Loop ;delayed branch

5 SD 8(R1),F4 ;altered when move past SUBI

Chap. 4 - Pipelining II

compiler perspectives on code movement15

Instruction Level Parallelism

Name Dependencies

Compiler Perspectives on Code Movement
  • Another kind of dependence called name dependence: two instructions use same name (register or memory location) but don’t exchange data
  • Anti-dependence (WAR if a hazard for HW)
    • Instruction j writes a register or memory location that instruction i reads from and instruction i is executed first
  • Output dependence (WAW if a hazard for HW)
    • Instruction i and instruction j write the same register or memory location; ordering between instructions must be preserved.

Chap. 4 - Pipelining II

compiler perspectives on code movement16

Instruction Level Parallelism

Name Dependencies

Compiler Perspectives on Code Movement

1 Loop: LD F0,0(R1)

2 ADDD F4,F0,F2

3 SD 0(R1),F4

4 LD F0,-8(R1)

5 ADDD F4,F0,F2

6 SD -8(R1),F4

7 LD F0,-16(R1)

8 ADDD F4,F0,F2

9 SD -16(R1),F4

10 LD F0,-24(R1)

11 ADDD F4,F0,F2

12 SD -24(R1),F4

13 SUBI R1,R1,#32

14 BNEZ R1,LOOP

15 NOP

How can we remove these dependencies?

Where are the name dependencies?

No data is passed in F0, but can’t reuse F0 in cycle 4.

Chap. 4 - Pipelining II

compiler perspectives on code movement17

Instruction Level Parallelism

Name Dependencies

Compiler Perspectives on Code Movement
  • Again Name Dependencies are Hard for Memory Accesses
    • Does 100(R4) = 20(R6)?
    • From different loop iterations, does 20(R6) = 20(R6)?
  • Our example required compiler to know that if R1 doesn’t change then:0(R1) ≠ -8(R1) ≠ -16(R1) ≠ -24(R1)

There were no dependencies between some loads and stores so they could be moved around each other

Chap. 4 - Pipelining II

slide18

Instruction Level Parallelism

Control Dependencies

Compiler Perspectives on Code Movement

  • Final kind of dependence called control dependence
  • Example

if p1 {S1;};

if p2 {S2;};

S1 is control dependent on p1 and S2 is control dependent on p2 but not on p1.

Chap. 4 - Pipelining II

slide19

Instruction Level Parallelism

Control Dependencies

Compiler Perspectives on Code Movement

  • Two (obvious) constraints on control dependences:
    • An instruction that is control dependenton a branch cannot be moved before the branch so that its execution is no longer controlled by the branch.
    • An instruction that is not control dependenton a branch cannot be moved to after the branch so that its execution is controlled by the branch.
  • Control dependencies relaxed to get parallelism; get same effect if preserve order of exceptions (address in register checked by branch before use) and data flow (value in register depends on branch)

Chap. 4 - Pipelining II

where are the control dependencies

Instruction Level Parallelism

Control Dependencies

Where are the control dependencies?

Compiler Perspectives on Code Movement

1 Loop: LD F0,0(R1)

2 ADDD F4,F0,F2

3 SD 0(R1),F4

4 SUBI R1,R1,8

5 BEQZ R1,exit

6 LD F0,0(R1)

7 ADDD F4,F0,F2

8 SD 0(R1),F4

9 SUBI R1,R1,8

10 BEQZ R1,exit

11 LD F0,0(R1)

12 ADDD F4,F0,F2

13 SD 0(R1),F4

14 SUBI R1,R1,8

15 BEQZ R1,exit

....

Chap. 4 - Pipelining II

when safe to unroll loop

Instruction Level Parallelism

Loop Level Parallelism

When Safe to Unroll Loop?
  • Example: Where are data dependencies? (A,B,C distinct & non-overlapping)

1. S2 uses the value, A[i+1], computed by S1 in the same iteration.

2. S1 uses a value computed by S1 in an earlier iteration, since iteration i computes A[i+1] which is read in iteration i+1. The same is true of S2 for B[i] and B[i+1]. This is a “loop-carried dependence” between iterations

  • Implies that iterations are dependent, and can’t be executed in parallel
  • Note the case for our prior example; each iteration was distinct

for (i=1; i<=100; i=i+1) { A[i+1] = A[i] + C[i]; /* S1 */ B[i+1] = B[i] + A[i+1]; /* S2 */}

Chap. 4 - Pipelining II

when safe to unroll loop22

Instruction Level Parallelism

Loop Level Parallelism

When Safe to Unroll Loop?
  • Example: Where are data dependencies? (A,B,C,D distinct & non-overlapping)

1. No dependence from S1 to S2. If there were, then there would be a cycle in the dependencies and the loop would not be parallel. Since this other dependence is absent, interchanging the two statements will not affect the execution of S2.

2. On the first iteration of the loop, statement S1 depends on the value of B[1] computed prior to initiating the loop.

for (i=1; i<=100; i=i+1) { A[i+1] = A[i] + B[i]; /* S1 */ B[i+1] = C[i] + D[i]; /* S2 */}

Chap. 4 - Pipelining II

now safe to unroll loop p 240

Instruction Level Parallelism

Loop Level Parallelism

Now Safe to Unroll Loop? (p. 240)

A[1] = A[1] + B[1];

for (i=1; i<=99; i=i+1) { B[i+1] = C[i] + D[i]; A[i+1] = + A[i+1] + B[i+1];}

B[101] = C[100] + D[100];

for (i=1; i<=100; i=i+1) { A[i+1] = A[i] + B[i]; /* S1 */ B[i+1] = C[i] + D[i];} /* S2 */

No circular dependencies.

OLD:

Loop caused dependence on B.

Have eliminated loop dependence.

NEW:

Chap. 4 - Pipelining II

dynamic scheduling
Dynamic Scheduling
  • Dynamic Scheduling is when the hardware rearranges the order of instruction execution to reduce stalls.
  • Advantages:
  • Dependencies unknown at compile time can be handled by the hardware.
  • Code compiled for one type of pipeline can be efficiently run on another.
  • Disadvantages:
  • Hardware much more complex.

4.1 Instruction Level Parallelism: Concepts and Challenges

4.2 Overcoming Data Hazards with Dynamic Scheduling

4.3 Reducing Branch Penalties with Dynamic Hardware Prediction

4.4 Taking Advantage of More ILP with Multiple Issue

4.5 Compiler Support for Exploiting ILP

4.6 Hardware Support for Extracting more Parallelism

4.7 Studies of ILP

Chap. 4 - Pipelining II

dynamic scheduling25

The idea:

Dynamic Scheduling

HW Schemes: Instruction Parallelism

  • Why in HW at run time?
    • Works when can’t know real dependence at compile time
    • Compiler simpler
    • Code for one machine runs well on another
  • Key Idea: Allow instructions behind stall to proceed.
  • Key Idea: Instructions executing in parallel. There are multiple execution units, so use them.

DIVD F0,F2,F4

ADDD F10,F0,F8

SUBD F12,F8,F14

    • Enables out-of-order execution => out-of-order completion

Chap. 4 - Pipelining II

dynamic scheduling26

The idea:

Dynamic Scheduling

HW Schemes: Instruction Parallelism

  • Out-of-order execution divides ID stage:

1. Issue—decode instructions, check for structural hazards

2. Read operands—wait until no data hazards, then read operands

  • Scoreboards allow instruction to execute whenever 1 & 2 hold, not waiting for prior instructions.
  • A scoreboard is a “data structure” that provides the information necessary for all pieces of the processor to work together.
  • We will use In order issue, out of order execution, out of order commit ( also called completion)
  • First used in CDC6600. Our example modified here for DLX.
  • CDC had 4 FP units, 5 memory reference units, 7 integer units.
  • DLX has 2 FP multiply, 1 FP adder, 1 FP divider, 1 integer.

Chap. 4 - Pipelining II

scoreboard implications

Dynamic Scheduling

Using A Scoreboard

Scoreboard Implications
  • Out-of-order completion => WAR, WAW hazards?
  • Solutions for WAR
    • Queue both the operation and copies of its operands
    • Read registers only during Read Operands stage
  • For WAW, must detect hazard: stall until other completes
  • Need to have multiple instructions in execution phase => multiple execution units or pipelined execution units
  • Scoreboard keeps track of dependencies, state or operations
  • Scoreboard replaces ID, EX, WB with 4 stages

Chap. 4 - Pipelining II

four stages of scoreboard control

Dynamic Scheduling

Using A Scoreboard

Four Stages of Scoreboard Control

1. Issue —decode instructions & check for structural hazards (ID1)

If a functional unit for the instruction is free and no other active instruction has the same destination register (WAW), the scoreboard issues the instruction to the functional unit and updates its internal data structure.

If a structural or WAW hazard exists, then the instruction issue stalls, and no further instructions will issue until these hazards are cleared.

Chap. 4 - Pipelining II

four stages of scoreboard control29

Dynamic Scheduling

Using A Scoreboard

Four Stages of Scoreboard Control

2. Read operands —wait until no data hazards, then read operands (ID2)

A source operand is available if no earlier issued active instruction is going to write it, or if the register containing the operand is being written by a currently active functional unit.

When the source operands are available, the scoreboard tells the functional unit to proceed to read the operands from the registers and begin execution. The scoreboard resolves RAW hazards dynamically in this step, and instructions may be sent into execution out of order.

Chap. 4 - Pipelining II

four stages of scoreboard control30

Dynamic Scheduling

Using A Scoreboard

Four Stages of Scoreboard Control

3. Execution—operate on operands (EX)

The functional unit begins execution upon receiving operands. When the result is ready, it notifies the scoreboard that it has completed execution.

4. Write result—finish execution (WB)

Once the scoreboard is aware that the functional unit has completed execution, the scoreboard checks for WAR hazards. If none, it writes results. If WAR, then it stalls the instruction.

Example:

DIVD F0,F2,F4

ADDD F10,F0,F8

SUBD F8,F8,F14

Scoreboard would stall SUBD until ADDD reads operands

Chap. 4 - Pipelining II

three parts of the scoreboard

Dynamic Scheduling

Using A Scoreboard

Three Parts of the Scoreboard

1. Instruction status—which of 4 steps the instruction is in

2. Functional unit status—Indicates the state of the functional unit (FU). 9 fields for each functional unit

Busy—Indicates whether the unit is busy or not

Op—Operation to perform in the unit (e.g., + or –)

Fi—Destination register

Fj, Fk—Source-register numbers

Qj, Qk—Functional units producing source registers Fj, Fk

Rj, Rk—Flags indicating when Fj, Fk are ready

3. Register result status—Indicates which functional unit will write each register, if one exists. Blank when no pending instructions will write that register

Chap. 4 - Pipelining II

detailed scoreboard pipeline control

Instruction status

Issue

Read operands

Execution complete

Write result

Dynamic Scheduling

Using A Scoreboard

Detailed Scoreboard Pipeline Control

Bookkeeping

Wait until

Busy(FU) yes; Op(FU) op; Fi(FU) `D’; Fj(FU) `S1’; Fk(FU) `S2’; Qj Result(‘S1’); Qk Result(`S2’); Rj not Qj; Rk not Qk; Result(‘D’) FU;

Not busy (FU) and not result(D)

Rj No; Rk No

Rj and Rk

Functional unit done

f(if Qj(f)=FU then Rj(f) Yes);f(if Qk(f)=FU then Rj(f) Yes); Result(Fi(FU)) 0; Busy(FU) No

f((Fj( f )≠Fi(FU) or Rj( f )=No) & (Fk( f ) ≠Fi(FU) or Rk( f )=No))

Chap. 4 - Pipelining II

scoreboard example

Dynamic Scheduling

Using A Scoreboard

Scoreboard Example

This is the sample code we’ll be working with in the example:

LD F6, 34(R2)

LD F2, 45(R3)

MULT F0, F2, F4

SUBD F8, F6, F2

DIVD F10, F0, F6

ADDD F6, F8, F2

What are the hazards in this code?

Latencies (clock cycles):

LD 1

MULT 10

SUBD 2

DIVD 40

ADDD 2

Chap. 4 - Pipelining II

scoreboard example34

Dynamic Scheduling

Using A Scoreboard

Scoreboard Example

Chap. 4 - Pipelining II

scoreboard example cycle 1

Dynamic Scheduling

Using A Scoreboard

Scoreboard Example Cycle 1

Issue LD #1

Shows in which cycle the operation occurred.

Chap. 4 - Pipelining II

scoreboard example cycle 2

Dynamic Scheduling

Using A Scoreboard

Scoreboard Example Cycle 2

LD #2 can’t issue since integer unit is busy.

MULT can’t issue because we require in-order issue.

Chap. 4 - Pipelining II

scoreboard example cycle 3

Dynamic Scheduling

Using A Scoreboard

Scoreboard Example Cycle 3

Chap. 4 - Pipelining II

scoreboard example cycle 4

Dynamic Scheduling

Using A Scoreboard

Scoreboard Example Cycle 4

Chap. 4 - Pipelining II

scoreboard example cycle 5

Dynamic Scheduling

Using A Scoreboard

Scoreboard Example Cycle 5

Issue LD #2 since integer unit is now free.

Chap. 4 - Pipelining II

scoreboard example cycle 6

Dynamic Scheduling

Using A Scoreboard

Scoreboard Example Cycle 6

Issue MULT.

Chap. 4 - Pipelining II

scoreboard example cycle 7

Dynamic Scheduling

Using A Scoreboard

Scoreboard Example Cycle 7

MULT can’t read its operands (F2) because LD #2 hasn’t finished.

Chap. 4 - Pipelining II

scoreboard example cycle 8a

Dynamic Scheduling

Using A Scoreboard

Scoreboard Example Cycle 8a

DIVD issues.

MULT and SUBD both waiting for F2.

Chap. 4 - Pipelining II

scoreboard example cycle 8b

Dynamic Scheduling

Using A Scoreboard

Scoreboard Example Cycle 8b

LD #2 writes F2.

Chap. 4 - Pipelining II

scoreboard example cycle 9

Dynamic Scheduling

Using A Scoreboard

Scoreboard Example Cycle 9

Now MULT and SUBD can both read F2.

How can both instructions do this at the same time??

Chap. 4 - Pipelining II

scoreboard example cycle 11

Dynamic Scheduling

Using A Scoreboard

Scoreboard Example Cycle 11

ADDD can’t start because add unit is busy.

Chap. 4 - Pipelining II

scoreboard example cycle 12

Dynamic Scheduling

Using A Scoreboard

Scoreboard Example Cycle 12

SUBD finishes.

DIVD waiting for F0.

Chap. 4 - Pipelining II

scoreboard example cycle 13

Dynamic Scheduling

Using A Scoreboard

Scoreboard Example Cycle 13

ADDD issues.

Chap. 4 - Pipelining II

scoreboard example cycle 14

Dynamic Scheduling

Using A Scoreboard

Scoreboard Example Cycle 14

Chap. 4 - Pipelining II

scoreboard example cycle 15

Dynamic Scheduling

Using A Scoreboard

Scoreboard Example Cycle 15

Chap. 4 - Pipelining II

scoreboard example cycle 16

Dynamic Scheduling

Using A Scoreboard

Scoreboard Example Cycle 16

Chap. 4 - Pipelining II

scoreboard example cycle 17

Dynamic Scheduling

Using A Scoreboard

Scoreboard Example Cycle 17

ADDD can’t write because of DIVD. RAW!

Chap. 4 - Pipelining II

scoreboard example cycle 18

Dynamic Scheduling

Using A Scoreboard

Scoreboard Example Cycle 18

Nothing Happens!!

Chap. 4 - Pipelining II

scoreboard example cycle 19

Dynamic Scheduling

Using A Scoreboard

Scoreboard Example Cycle 19

MULT completes execution.

Chap. 4 - Pipelining II

scoreboard example cycle 20

Dynamic Scheduling

Using A Scoreboard

Scoreboard Example Cycle 20

MULT writes.

Chap. 4 - Pipelining II

scoreboard example cycle 21

Dynamic Scheduling

Using A Scoreboard

Scoreboard Example Cycle 21

DIVD loads operands

Chap. 4 - Pipelining II

scoreboard example cycle 22

Dynamic Scheduling

Using A Scoreboard

Scoreboard Example Cycle 22

Now ADDD can write since WAR removed.

Chap. 4 - Pipelining II

scoreboard example cycle 61

Dynamic Scheduling

Using A Scoreboard

Scoreboard Example Cycle 61

DIVD completes execution

Chap. 4 - Pipelining II

scoreboard example cycle 62

Dynamic Scheduling

Using A Scoreboard

Scoreboard Example Cycle 62

DONE!!

Chap. 4 - Pipelining II

another dynamic algorithm tomasulo algorithm

Dynamic Scheduling

Using A Scoreboard

Another Dynamic Algorithm: Tomasulo Algorithm
  • For IBM 360/91 about 3 years after CDC 6600 (1966)
  • Goal: High Performance without special compilers
  • Differences between IBM 360 & CDC 6600 ISA
    • IBM has only 2 register specifiers / instruction vs. 3 in CDC 6600
    • IBM has 4 FP registers vs. 8 in CDC 6600
  • Why Study? lead to Alpha 21264, HP 8000, MIPS 10000, Pentium II, PowerPC 604, …

Chap. 4 - Pipelining II

tomasulo algorithm vs scoreboard

Dynamic Scheduling

Using A Scoreboard

Tomasulo Algorithm vs. Scoreboard
  • Control & buffers distributed with Function Units (FU) vs. centralized in scoreboard;
    • FU buffers called “reservation stations”; have pending operands
  • Registers in instructions replaced by values or pointers to reservation stations(RS); called registerrenaming;
    • avoids WAR, WAW hazards
    • More reservation stations than registers, so can do optimizations compilers can’t
  • Results to FU from RS, not through registers, over Common DataBusthat broadcasts results to all FUs
  • Load and Stores treated as FUs with RSs as well
  • Integer instructions can go past branches, allowing FP ops beyond basic block in FP queue

Chap. 4 - Pipelining II

tomasulo organization

Using A Scoreboard

Dynamic Scheduling

Tomasulo Organization

FPRegisters

FP Op Queue

LoadBuffer

StoreBuffer

CommonDataBus

FP AddRes.Station

FP MulRes.Station

Chap. 4 - Pipelining II

reservation station components

Dynamic Scheduling

Using A Scoreboard

Reservation Station Components

Op—Operation to perform in the unit (e.g., + or –)

Vj, Vk—Value of Source operands

  • Store buffers have V field, result to be stored

Qj, Qk—Reservation stations producing source registers (value to be written)

  • Note: No ready flags as in Scoreboard; Qj,Qk=0 => ready
  • Store buffers only have Qi for RS producing result

Busy—Indicates reservation station or FU is busy

Register result status—Indicates which functional unit will write each register, if one exists. Blank when no pending instructions that will write that register.

Chap. 4 - Pipelining II

three stages of tomasulo algorithm

Dynamic Scheduling

Using A Scoreboard

Three Stages of Tomasulo Algorithm

1. Issue—get instruction from FP Op Queue

If reservation station free (no structural hazard), control issues instruction & sends operands (renames registers).

2. Execution—operate on operands (EX)

When both operands ready then execute; if not ready, watch Common Data Bus for result

3. Write result—finish execution (WB)

Write on Common Data Bus to all awaiting units; mark reservation station available

  • Normal data bus: data + destination (“go to” bus)
  • Common data bus: data + source (“come from” bus)
    • 64 bits of data + 4 bits of Functional Unit source address
    • Write if matches expected Functional Unit (produces result)
    • Does the broadcast

Chap. 4 - Pipelining II

tomasulo example cycle 0

Dynamic Scheduling

Using A Scoreboard

Tomasulo Example Cycle 0

Chap. 4 - Pipelining II

review tomasulo

Dynamic Scheduling

Using A Scoreboard

Review: Tomasulo
  • Prevents Register as bottleneck
  • Avoids WAR, WAW hazards of Scoreboard
  • Allows loop unrolling in HW
  • Not limited to basic blocks (provided branch prediction)
  • Lasting Contributions
    • Dynamic scheduling
    • Register renaming
    • Load/store disambiguation
  • 360/91 descendants are PowerPC 604, 620; MIPS R10000; HP-PA 8000; Intel Pentium Pro

Chap. 4 - Pipelining II

dynamic hardware prediction
Dynamic Hardware Prediction

Dynamic Branch Prediction is the ability of the hardware to make an educated guess about which way a branch will go - will the branch be taken or not.

The hardware can look for clues based on the instructions, or it can use past history - we will discuss both of these directions.

4.1 Instruction Level Parallelism: Concepts and Challenges

4.2 Overcoming Data Hazards with Dynamic Scheduling

4.3 Reducing Branch Penalties with Dynamic Hardware Prediction

4.4 Taking Advantage of More ILP with Multiple Issue

4.5 Compiler Support for Exploiting ILP

4.6 Hardware Support for Extracting more Parallelism

4.7 Studies of ILP

Chap. 4 - Pipelining II

dynamic branch prediction

Dynamic Hardware Prediction

Basic Branch Prediction:

Branch Prediction Buffers

Dynamic Branch Prediction
  • Performance = ƒ(accuracy, cost of misprediction)
  • Branch History Lower bits of PC address index table of 1-bit values
    • Says whether or not branch taken last time
  • Problem: in a loop, 1-bit BHT will cause two mis-predictions:
    • End of loop case, when it exits instead of looping as before
    • First time through loop on next time through code, when it predicts exit instead of looping

Bits 13 - 2

Prediction

Address

0

31 1

1023

Chap. 4 - Pipelining II

dynamic branch prediction68

T

NT

Predict Taken

Predict Taken

T

T

NT

NT

Predict Not

Taken

Predict Not

Taken

T

NT

Dynamic Hardware Prediction

Basic Branch Prediction:

Branch Prediction Buffers

Dynamic Branch Prediction
  • Solution: 2-bit scheme where change prediction only if get misprediction twice: (Figure 4.13, p. 264)

Chap. 4 - Pipelining II

bht accuracy

Dynamic Hardware Prediction

Basic Branch Prediction:

Branch Prediction Buffers

BHT Accuracy
  • Mispredict because either:
    • Wrong guess for that branch
    • Got branch history of wrong branch when index the table
  • 4096 entry table programs vary from 1% misprediction (nasa7, tomcatv) to 18% (eqntott), with spice at 9% and gcc at 12%
  • 4096 about as good as infinite table, but 4096 is a lot of HW

Chap. 4 - Pipelining II

correlating branches

Branch address

2-bits per branch predictors

Prediction

2-bit global branch history

Dynamic Hardware Prediction

Basic Branch Prediction:

Branch Prediction Buffers

Correlating Branches

Idea: taken/not taken of recently executed branches is related to behavior of next branch (as well as the history of that branch behavior)

  • Then behavior of recent branches selects between, say, four predictions of next branch, updating just that prediction

Chap. 4 - Pipelining II

accuracy of different schemes

Dynamic Hardware Prediction

Basic Branch Prediction:

Branch Prediction Buffers

Accuracy of Different Schemes

(Figure 4.21, p. 272)

4096 Entries 2-bits per entry

Unlimited Entries 2-bits per entry

1024 Entries - 2 bits of history,

2 bits per entry

18%

Frequency of Mispredictions

0%

Chap. 4 - Pipelining II

branch target buffer

Dynamic Hardware Prediction

Basic Branch Prediction:

Branch Target Buffers

Branch Target Buffer
  • Branch Target Buffer (BTB): Use address of branch as index to get prediction AND branch address (if taken)
    • Note: must check for branch match now, since can’t use wrong branch address (Figure 4.22, p. 273)
  • Return instruction addresses predicted with stack

Predicted PC

Branch Prediction:

Taken or not Taken

Chap. 4 - Pipelining II

example

Dynamic Hardware Prediction

Basic Branch Prediction:

Branch Target Buffers

Example

Instructions Prediction Actual Penalty

in Buffer Branch Cycles

Yes Taken Taken 0

Yes Taken Not taken 2

No Taken 2

Example on page 274.

Determine the total branch penalty for a BTB using the above penalties. Assume also the following:

  • Prediction accuracy of 80%
  • Hit rate in the buffer of 90%
  • 60% taken branch frequency.

Branch Penalty = Percent buffer hit rate X Percent incorrect predictions X 2 + ( 1 - percent buffer hit rate) X Taken branches X 2

Branch Penalty = ( 90% X 10% X 2) + (10% X 60% X 2)

Branch Penalty = 0.18 + 0.12 = 0.30 clock cycles

Chap. 4 - Pipelining II

multiple issue
Multiple Issue

Multiple Issue is the ability of the processor to start more than one instruction in a given cycle.

Flavor I:

Superscalar processors issue varying number of instructions per clock - can be either statically scheduled (by the compiler) or dynamically scheduled (by the hardware).

Superscalar has a varying number of instructions/cycle (1 to 8), scheduled by compiler or by HW (Tomasulo).

IBM PowerPC, Sun UltraSparc, DEC Alpha, HP 8000

4.1 Instruction Level Parallelism: Concepts and Challenges

4.2 Overcoming Data Hazards with Dynamic Scheduling

4.3 Reducing Branch Penalties with Dynamic Hardware Prediction

4.4 Taking Advantage of More ILP with Multiple Issue

4.5 Compiler Support for Exploiting ILP

4.6 Hardware Support for Extracting more Parallelism

4.7 Studies of ILP

Chap. 4 - Pipelining II

issuing multiple instructions cycle

Multiple Issue

Issuing Multiple Instructions/Cycle

Flavor II:

VLIW - Very Long Instruction Word - issues a fixed number of instructions formatted either as one very large instruction or as a fixed packet of smaller instructions.

fixed number of instructions (4-16) scheduled by the compiler; put operators into wide templates

  • Joint HP/Intel agreement in 1999/2000
  • Intel Architecture-64 (IA-64) 64-bit address
  • Style: “Explicitly Parallel Instruction Computer (EPIC)”

Chap. 4 - Pipelining II

issuing multiple instructions cycle76

Multiple Issue

Issuing Multiple Instructions/Cycle

Flavor II - continued:

  • 3 Instructions in 128 bit “groups”; field determines if instructions dependent or independent
    • Smaller code size than old VLIW, larger than x86/RISC
    • Groups can be linked to show independence > 3 instr
  • 64 integer registers + 64 floating point registers
    • Not separate files per functional unit as in old VLIW
  • Hardware checks dependencies (interlocks => binary compatibility over time)
  • Predicated execution (select 1 out of 64 1-bit flags) => 40% fewer mis-predictions?
  • IA-64 : name of instruction set architecture; EPIC is type
  • Merced is name of first implementation (1999/2000?)

Chap. 4 - Pipelining II

issuing multiple instructions cycle77

Multiple Issue

A SuperScalar Version of DLX

Issuing Multiple Instructions/Cycle
  • In our DLX example, we can handle 2 instructions/cycle:
  • Floating Point
  • Anything Else

– Fetch 64-bits/clock cycle; Int on left, FP on right

– Can only issue 2nd instruction if 1st instruction issues

– More ports for FP registers to do FP load & FP op in a pair

Type Pipe Stages

Int. instruction IF ID EX MEM WB

FP instruction IF ID EX MEM WB

Int. instruction IF ID EX MEM WB

FP instruction IF ID EX MEM WB

Int. instruction IF ID EX MEM WB

FP instruction IF ID EX MEM WB

  • 1 cycle load delay causes delay to 3 instructions in Superscalar
    • instruction in right half can’t use it, nor instructions in next slot

Chap. 4 - Pipelining II

unrolled loop minimizes stalls for scalar

Multiple Issue

A SuperScalar Version of DLX

Unrolled Loop Minimizes Stalls for Scalar

1 Loop: LD F0,0(R1)

2 LD F6,-8(R1)

3 LD F10,-16(R1)

4 LD F14,-24(R1)

5 ADDD F4,F0,F2

6 ADDD F8,F6,F2

7 ADDD F12,F10,F2

8 ADDD F16,F14,F2

9 SD 0(R1),F4

10 SD -8(R1),F8

11 SD -16(R1),F12

12 SUBI R1,R1,#32

13 BNEZ R1,LOOP

14 SD 8(R1),F16 ; 8-32 = -24

14 clock cycles, or 3.5 per iteration

Latencies:

LD to ADDD: 1 Cycle

ADDD to SD: 2 Cycles

Chap. 4 - Pipelining II

loop unrolling in superscalar

Multiple Issue

A SuperScalar Version of DLX

Loop Unrolling in Superscalar

Integer instruction FP instruction Clock cycle

Loop: LD F0,0(R1) 1

LD F6,-8(R1) 2

LD F10,-16(R1) ADDD F4,F0,F2 3

LD F14,-24(R1) ADDD F8,F6,F2 4

LD F18,-32(R1) ADDD F12,F10,F2 5

SD 0(R1),F4 ADDD F16,F14,F2 6

SD -8(R1),F8 ADDD F20,F18,F2 7

SD -16(R1),F12 8

SD -24(R1),F16 9

SUBI R1,R1,#40 10

BNEZ R1,LOOP 11

SD 8(R1),F20 12

  • Unrolled 5 times to avoid delays (+1 due to SS)
  • 12 clocks, or 2.4 clocks per iteration

Chap. 4 - Pipelining II

dynamic scheduling in superscalar

Multiple Issue

Multiple Instruction Issue & Dynamic Scheduling

Dynamic Scheduling in Superscalar

Code compiler for scalar version will run poorly on Superscalar

May want code to vary depending on how Superscalar

Simple approach: separate Tomasulo Control for separate reservation stations for Integer FU/Reg and for FP FU/Reg

Chap. 4 - Pipelining II

dynamic scheduling in superscalar81

Multiple Issue

Multiple Instruction Issue & Dynamic Scheduling

Dynamic Scheduling in Superscalar
  • How to do instruction issue with two instructions and keep in-order instruction issue for Tomasulo?
    • Issue 2X Clock Rate, so that issue remains in order
    • Only FP loads might cause dependency between integer and FP issue:
      • Replace load reservation station with a load queue; operands must be read in the order they are fetched
      • Load checks addresses in Store Queue to avoid RAW violation
      • Store checks addresses in Load Queue to avoid WAR,WAW

Chap. 4 - Pipelining II

performance of dynamic superscalar

Multiple Issue

Multiple Instruction Issue & Dynamic Scheduling

Performance of Dynamic Superscalar

Iteration Instructions Issues Executes Writes result

no. clock-cycle number

1 LD F0,0(R1) 1 2 4

1 ADDD F4,F0,F2 1 5 8

1 SD 0(R1),F4 2 9

1 SUBI R1,R1,#8 3 4 5

1 BNEZ R1,LOOP 4 5

2 LD F0,0(R1) 5 6 8

2 ADDD F4,F0,F2 5 9 12

2 SD 0(R1),F4 6 13

2 SUBI R1,R1,#8 7 8 9

2 BNEZ R1,LOOP 8 9

­ 4 clocks per iteration

Branches, Decrements still take 1 clock cycle

Chap. 4 - Pipelining II

loop unrolling in vliw

Multiple Issue

VLIW

Loop Unrolling in VLIW

Memory Memory FP FP Int. op/ Clockreference 1 reference 2 operation 1 op. 2 branch

LD F0,0(R1) LD F6,-8(R1) 1

LD F10,-16(R1) LD F14,-24(R1) 2

LD F18,-32(R1) LD F22,-40(R1) ADDD F4,F0,F2 ADDD F8,F6,F2 3

LD F26,-48(R1) ADDD F12,F10,F2 ADDD F16,F14,F2 4

ADDD F20,F18,F2 ADDD F24,F22,F2 5

SD 0(R1),F4 SD -8(R1),F8 ADDD F28,F26,F2 6

SD -16(R1),F12 SD -24(R1),F16 7

SD -32(R1),F20 SD -40(R1),F24 SUBI R1,R1,#48 8

SD -0(R1),F28 BNEZ R1,LOOP 9

  • Unrolled 7 times to avoid delays
  • 7 results in 9 clocks, or 1.3 clocks per iteration
  • Need more registers to effectively use VLIW

Chap. 4 - Pipelining II

limits to multi issue machines

Multiple Issue

Limitations With Multiple Issue

Limits to Multi-Issue Machines
  • Inherent limitations of ILP
    • 1 branch in 5 instructions => how to keep a 5-way VLIW busy?
    • Latencies of units => many operations must be scheduled
    • Need about Pipeline Depth x No. Functional Units of independent operations to keep machines busy.
  • Difficulties in building HW
    • Duplicate Functional Units to get parallel execution
    • Increase ports to Register File (VLIW example needs 6 read and 3 write for Int. Reg. & 6 read and 4 write for Reg.)
    • Increase ports to memory
    • Decoding SS and impact on clock rate, pipeline depth

Chap. 4 - Pipelining II

limits to multi issue machines85

Multiple Issue

Limitations With Multiple Issue

Limits to Multi-Issue Machines
  • Limitations specific to either SS or VLIW implementation
    • Decode issue in SS
    • VLIW code size: unroll loops + wasted fields in VLIW
    • VLIW lock step => 1 hazard & all instructions stall
    • VLIW & binary compatibility

Chap. 4 - Pipelining II

multiple issue challenges

Multiple Issue

Limitations With Multiple Issue

Multiple Issue Challenges
  • While Integer/FP split is simple for the HW, get CPI of 0.5 only for programs with:
    • Exactly 50% FP operations
    • No hazards
  • If more instructions issue at same time, greater difficulty of decode and issue
    • Even 2-scalar => examine 2 opcodes, 6 register specifiers, & decide if 1 or 2 instructions can issue
  • VLIW: tradeoff instruction space for simple decoding
    • The long instruction word has room for many operations
    • By definition, all the operations the compiler puts in the long instruction word are independent => execute in parallel
    • E.g., 2 integer operations, 2 FP ops, 2 Memory refs, 1 branch
      • 16 to 24 bits per field => 7*16 or 112 bits to 7*24 or 168 bits wide
    • Need compiling technique that schedules across several branches

Chap. 4 - Pipelining II

compiler support for ilp
Compiler Support For ILP
  • How can compilers be smart?
  • 1. Produce good scheduling of code.
  • 2. Determine which loops might contain parallelism.
  • 3. Eliminate name dependencies.
  • Compilers must be REALLY smart to figure out aliases -- pointers in C are a real problem.
  • Techniques lead to:
    • Symbolic Loop Unrolling
    • Critical Path Scheduling

4.1 Instruction Level Parallelism: Concepts and Challenges

4.2 Overcoming Data Hazards with Dynamic Scheduling

4.3 Reducing Branch Penalties with Dynamic Hardware Prediction

4.4 Taking Advantage of More ILP with Multiple Issue

4.5 Compiler Support for Exploiting ILP

4.6 Hardware Support for Extracting more Parallelism

4.7 Studies of ILP

Chap. 4 - Pipelining II

software pipelining

Compiler Support For ILP

Symbolic Loop Unrolling

Software Pipelining
  • Observation: if iterations from loops are independent, then can get ILP by taking instructions from different iterations
  • Software pipelining: reorganizes loops so that each iteration is made from instructions chosen from different iterations of the original loop (Tomasulo in SW)

Chap. 4 - Pipelining II

sw pipelining example

Compiler Support For ILP

Symbolic Loop Unrolling

SW Pipelining Example

After: Software Pipelined

LD F0,0(R1)

ADDD F4,F0,F2

LD F0,-8(R1)

1 SD 0(R1),F4; Stores M[i]

2 ADDD F4,F0,F2; Adds to M[i-1]

3 LD F0,-16(R1); loads M[i-2]

4 SUBI R1,R1,#8

5 BNEZ R1,LOOP

SD 0(R1),F4

ADDD F4,F0,F2

SD -8(R1),F4

Before: Unrolled 3 times

1 LD F0,0(R1)

2 ADDD F4,F0,F2

3 SD 0(R1),F4

4 LD F6,-8(R1)

5 ADDD F8,F6,F2

6 SD -8(R1),F8

7 LD F10,-16(R1)

8 ADDD F12,F10,F2

9 SD -16(R1),F12

10 SUBI R1,R1,#24

11 BNEZ R1,LOOP

Read F4

Read F0

SD

ADDD

LD

IF ID EX Mem WB

IF ID EX Mem WB

IF ID EX Mem WB

Write F4

Write F0

Chap. 4 - Pipelining II

sw pipelining example90

Compiler Support For ILP

Symbolic Loop Unrolling

SW Pipelining Example
  • Symbolic Loop Unrolling
    • Less code space
    • Overhead paid only once vs. each iteration in loop unrolling

Software Pipelining

Loop Unrolling

100 iterations = 25 loops with 4 unrolled iterations each

Chap. 4 - Pipelining II

trace scheduling

Compiler Support For ILP

Critical Path Scheduling

Trace Scheduling
  • Parallelism across IF branches vs. LOOP branches
  • Two steps:
    • Trace Selection
      • Find likely sequence of basic blocks (trace) of (statically predicted or profile predicted) long sequence of straight-line code
    • Trace Compaction
      • Squeeze trace into few VLIW instructions
      • Need bookkeeping code in case prediction is wrong
  • Compiler undoes bad guess (discards values in registers)
  • Subtle compiler bugs mean wrong answer vs. poorer performance; no hardware interlocks

Chap. 4 - Pipelining II

hardware support for parallelism
Hardware Support For Parallelism
  • Software support of ILP is best when code is predictable at compile time.
  • But what if there’s no predictability?
  • Here we’ll talk about hardware techniques. These include:
  • Conditional or Predicated Instructions
  • Hardware Speculation

4.1 Instruction Level Parallelism: Concepts and Challenges

4.2 Overcoming Data Hazards with Dynamic Scheduling

4.3 Reducing Branch Penalties with Dynamic Hardware Prediction

4.4 Taking Advantage of More ILP with Multiple Issue

4.5 Compiler Support for Exploiting ILP

4.6 Hardware Support for Extracting more Parallelism

4.7 Studies of ILP

Chap. 4 - Pipelining II

tell the hardware to ignore an instruction

Hardware Support For Parallelism

Nullified Instructions

Tell the Hardware To Ignore An Instruction
  • Avoid branch prediction by turning branches into conditionally executed instructions:

IF (x) then A = B op C else NOP

    • If false, then neither store result nor cause exception
    • Expanded ISA of Alpha, MIPs, PowerPC, SPARC, have conditional move. PA-RISC can annul any following instruction.
    • IA-64: 64 1-bit condition fields selected so conditional execution of any instruction
  • Drawbacks to conditional instructions:
    • Still takes a clock, even if “annulled”
    • Stalls if condition evaluated late
    • Complex conditions reduce effectiveness; condition becomes known late in pipeline.

This can be a major win because there is no time lost by taking a branch!!

x

A =

B op C

Chap. 4 - Pipelining II

tell the hardware to ignore an instruction94

Hardware Support For Parallelism

Nullified Instructions

Tell the Hardware To Ignore An Instruction

Suppose we have the code:

if ( VarA == 0 )

VarS = VarT;

Previous Method:

LD R1, VarA

BNEZ R1, Label

LD R2, VarT

SD VarS, R2

Label:

Nullified Method:

LD R1, VarA

LD R2, VarT

CMPNNZ R1, #0

SD VarS, R2

Label:

Compare and Nullify Next Instr. If Not Zero

Nullified Method:

LD R1, VarA

LD R2, VarT

CMOVZ VarS,R2, R1

Compare and Move IF Zero

Chap. 4 - Pipelining II

hardware support for parallelism95

Compiler Speculation

Hardware Support For Parallelism

Increasing Parallelism

The theory here is to move an instruction across a branch so as to increase the size of a basic block and thus to increase parallelism.

Primary difficulty is in avoiding exceptions. For example

if ( a ^= 0 ) c = b/a; may have divide by zero error in some cases.

Methods for increasing speculation include:

1. Use a set of status bits (poison bits) associated with the registers. Are a signal that the instruction results are invalid until some later time.

2. Result of instruction isn’t written until it’s certain the instruction is no longer speculative.

Chap. 4 - Pipelining II

hardware support for parallelism96

Compiler Speculation

Hardware Support For Parallelism

Increasing Parallelism

Original Code:

LW R1, 0(R3) Load A

BNEZ R1, L1 Test A

LW R1, 0(R2) If Clause

J L2 Skip Else

L1: ADDI R1, R1, #4 Else Clause

L2: SW 0(R3), R1 Store A

Example on Page 305.

Code for

if ( A == 0 )

A = B;

else

A = A + 4;

Assume A is at 0(R3) and B is at 0(R4)

Speculated Code:

LW R1, 0(R3) Load A

LW R14, 0(R2) Spec Load B

BEQZ R1, L3 Other if Branch

ADDI R14, R1, #4 Else Clause

L3: SW 0(R3), R14 Non-Spec Store

Note here that only ONE side needs to take a branch!!

Chap. 4 - Pipelining II

hardware support for parallelism97

Compiler Speculation

Hardware Support For Parallelism

Poison Bits

In the example on the last page, if the LW* produces an exception, a poison bit is set on that register. The if a later instruction tries to use the register, an exception is THEN raised.

Speculated Code:

LW R1, 0(R3) Load A

LW* R14, 0(R2) Spec Load B

BEQZ R1, L3 Other if Branch

ADDI R14, R1, #4 Else Clause

L3: SW 0(R3), R14 Non-Spec Store

Chap. 4 - Pipelining II

hw support for more ilp

Reorder

Buffer

FP

Op

Queue

FP Regs

Res Stations

Res Stations

FP Adder

FP Adder

Figure 4.34, page 311

Hardware Support For Parallelism

Hardware Speculation

HW support for More ILP
  • Need HW buffer for results of uncommitted instructions: reorder buffer
    • Reorder buffer can be operand source
    • Once operand commits, result is found in register
    • 3 fields: instr. type, destination, value
    • Use reorder buffer number instead of reservation station
    • Discard instructions on mis-predicted branches or on exceptions

Chap. 4 - Pipelining II

hw support for more ilp99

Hardware Support For Parallelism

Hardware Speculation

HW support for More ILP

How is this used in practice?

Rather than predicting the direction of a branch, execute the instructions on both side!!

We early on know the target of a branch, long before we know it if will be taken or not.

So begin fetching/executing at that new Target PC.

But also continue fetching/executing as if the branch NOT taken.

Chap. 4 - Pipelining II

studies of ilp
Studies of ILP
  • Conflicting studies of amount of improvement available
    • Benchmarks (vectorized FP Fortran vs. integer C programs)
    • Hardware sophistication
    • Compiler sophistication
  • How much ILP is available using existing mechanisms with increasing HW budgets?
  • Do we need to invent new HW/SW mechanisms to keep on processor performance curve?

4.1 Instruction Level Parallelism: Concepts and Challenges

4.2 Overcoming Data Hazards with Dynamic Scheduling

4.3 Reducing Branch Penalties with Dynamic Hardware Prediction

4.4 Taking Advantage of More ILP with Multiple Issue

4.5 Compiler Support for Exploiting ILP

4.6 Hardware Support for Extracting more Parallelism

4.7 Studies of ILP

Chap. 4 - Pipelining II

limits to ilp

Studies of ILP

Limits to ILP

Initial HW Model here; MIPS compilers.

Assumptions for ideal/perfect machine to start:

1. Register renaming–infinite virtual registers and all WAW & WAR hazards are avoided

2. Branch prediction–perfect; no mispredictions

3. Jump prediction–all jumps perfectly predicted => machine with perfect speculation & an unbounded buffer of instructions available

4. Memory-address alias analysis–addresses are known & a store can be moved before a load provided addresses not equal

1 cycle latency for all instructions; unlimited number of instructions issued per clock cycle

Chap. 4 - Pipelining II

upper limit to ilp ideal machine figure 4 38 page 319

Studies of ILP

Upper Limit to ILP: Ideal Machine(Figure 4.38, page 319)

This is the amount of parallelism when there are no branch mis-predictions and we’re limited only by data dependencies.

FP: 75 - 150

Integer: 18 - 60

IPC

Instructions that could theoretically be issued per cycle.

Chap. 4 - Pipelining II

impact of realistic branch prediction

Studies of ILP

Impact of Realistic Branch Prediction

What parallelism do we get when we don’t allow perfect branch prediction, as in the last picture, but assume some realistic model?

Possibilities include:

1. Perfect - all branches are perfectly predicted (the last slide)

2. Selective History Predictor - a complicated but do-able mechanism for selection.

3. Standard 2-bit history predictor with 512 2-bit entries.

4. Static prediction based on past history of the program.

5. None - Parallelism is limited to basic block.

Chap. 4 - Pipelining II

selective history predictor

Studies of ILP

Bonus!!

Selective History Predictor

8096 x 2 bits

1

0

Taken/Not Taken

11

10

01

00

Choose Non-correlator

Branch Addr

Choose Correlator

2

Global

History

00

8K x 2 bit

Selector

01

10

11

11 Taken

10

01 Not Taken

00

2048 x 4 x 2 bits

Chap. 4 - Pipelining II

impact of realistic branch prediction figure 4 42 page 325

Studies of ILP

Impact of Realistic Branch PredictionFigure 4.42, Page 325

FP: 15 - 45

Limiting the type of branch prediction.

Integer: 6 - 12

IPC

Chap. 4 - Pipelining II

Perfect

Selective Hist

BHT (512)

Profile

No prediction

more realistic hw register impact figure 4 44 page 328

Studies of ILP

More Realistic HW: Register ImpactFigure 4.44, Page 328

FP: 11 - 45

Effect of limiting the number of renaming registers.

Integer: 5 - 15

IPC

Chap. 4 - Pipelining II

Infinite

256

128

64

32

None

more realistic hw alias impact figure 4 46 page 330

Studies of ILP

More Realistic HW: Alias ImpactFigure 4.46, Page 330

FP: 4 - 45

(Fortran,

no heap)

What happens when there may be conflicts with memory aliasing?

Integer: 4 - 9

IPC

Global/Stack perf;heap conflicts

Perfect

Inspec.Assem.

None

Chap. 4 - Pipelining II

summary
Summary

4.1 Instruction Level Parallelism: Concepts and Challenges

4.2 Overcoming Data Hazards with Dynamic Scheduling

4.3 Reducing Branch Penalties with Dynamic Hardware Prediction

4.4 Taking Advantage of More ILP with Multiple Issue

4.5 Compiler Support for Exploiting ILP

4.6 Hardware Support for Extracting more Parallelism

4.7 Studies of ILP

Chap. 4 - Pipelining II