UNIT – 2

STATIC MULTIPLE ISSUE: THE VLIW APPROACH

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

Flavor I: Superscalar processors

· in-order issue varying number of instructions per clock (1-8)

· either statically scheduled (by the compiler) or dynamically scheduled (by the hardware, Tomasulo)

Flavor II: Very Long Instruction Word (VLIW)

· parallel issue a fixed number of instructions (4-16)

- compilers choose instructions to be issued simultaneously

· formatted either as one very large instruction or as a fixed issue packet of smaller instructions

- rigid in early VLIWs

· dependency checked and instruction scheduled by the compiler

- simplifying hardware (maybe no or simpler dependency check)

- complex compiler to uncovered enough parallelism

· loop unrolling

· local scheduling: operate on a single basic block

· global scheduling: may move code across branches

· Style: “Explicitly Parallel Instruction Computer (EPIC)”

- Intel Architecture-64 (IA-64) 64-bit address

- Joint HP/Intel agreement in 1999/2000 .

Unrolled version (x[i]=x[i]+s)

23 operations in 9 clock cycles (2.5 operations per cycle) - 9 cycle for 1 iteration for the base

Unroll 7 iterations in 9 cycles (1.29 cycles per loop) - 2.4 for unrolled 5 and scheduled version

Require at least 8 FP registers for VLIW - 2 FP registers for the base

- 5 FP registers for unrolled 5 and scheduled version 22/(5*9)=48.9% of functional units are empty

VLIW: 2 mem’s, 2 FPs, 1 Int/Brx (ignore branch delayed slot)

Problems in VLIW Approach

Technical problems

· increase in code size

· unrolling

· wasted bits for unused functional units in instruction encoding

solutions: clever encoding, compress

· limitations of lockstep operation – synchronization restriction

· To keep all functional units (FU) synchronized, a stall in any FU pipeline must cause the entire processor to stall, i.e. cache stall, exception

recent solutions: FU operate more independently, hardware checks allow for unsynchronized execution once instructions are issued

Logistical problem – migration problem

· binary code compatibility – recompilation required for different numbers of FUs and unit latencies

solution: object-code translation or emulation.

Advanced 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

Two important ideas:

Software Pipelining - Symbolic Loop Unrolling

Trace Scheduling - Critical Path Scheduling

Loop-carried dependence: data accesses in later iterations are dependent on data values produced in earlier iterations

structures analyzed at source level by compilers, such as

· loops

· array references

· induction variable computations

Loop-level parallelism

· dependence between two uses of x[i]

· dependent within a single iteration, not loop carried

· A loop is parallel if it can written without a cycle in the dependences, since the absence of a cycle means that the dependences give a partial ordering on the statements

Assume A, B, and C are distinct, non-overlapping arrays

Two different dependences

1. Dependence of S1 is on an earlier iteration of S1

S1: A[i+1] depends on A[i], S2: B[i+1] depends on B[i]

forces successive iterations to execute in series

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

Multiple iterations of the loop could execute in parallel

Loop-carried dependence between S2 (B[i+1]) and S1 (B[i])

· not circular: neither statement depends on itself

· S1 depends on S2, but S2 does not depend on S1

This loop can be made parallel

Interchanging

· no longer loop carried

1. True dependences from S1 to S3 and from S1 to S4, based on Y[i]

· not loop carried

2. antidependence from S1 to S2, based on X[i]

3. antidependence from S3 to S4 for Y[i]

4. output dependence from S1 to S4, based on Y[i]

Software Pipelining

· Observation: if iterations from loops are independent, then can get ILP by taking instructions from different iterations

· Software pipelining: interleave instructions from different loop iterations

· reorganizes loops so that each iteration is made from instructions chosen from different iterations of the original loop (Tomasulo in SW)

LOOP:1L.DF0,0(R1)

2ADD.DF4,F0,F2

3S.DF4,0(R1)

4DADDUIR1,R1,#8

5BNER1,R2,LOOP

1 L.DF0,0(R1)4 L.DF0,0(R1)7L.DF0,-16(R1)

2ADD.DF4,F0,F25ADD.DF4,F0,F28ADD.DF4,F0,F2

3S.DF4,0(R1) 6S.DF4,0(R1) 9S.DF4,-16(R1)

Before: Unrolled 3 times (11/11)

1 L.DF0,0(R1)

2ADD.DF4,F0,F2

3S.DF4,0(R1)

4L.DF0,-8(R1)

5ADD.DF4,F0,F2

6S.DF4,-8(R1)

7L.DF0,-16(R1)

8ADD.DF4,F0,F2

9S.DF4,-16(R1)

10DADDUIR1,R1,#24

11BNER1,R2,LOOP

After: Software Pipelined (5/11)

1L.DF0,0(R1)

2ADD.DF4,F0,F2

4L.DF0,-8(R1)

3S.DF4,0(R1); Stores M[i]

5ADD.DF4,F0,F2; Adds to M[i-1]

7L.DF0,-16(R1); loads M[i-2]

10DADDUIR1,R1,#8

11BNER1,R2,LOOP

6S.DF4,-8(R1)

8ADD.DF4,F0,F2

9S.DF4,-16(R1)

Software Pipelining and Loop Unrolling

· Software pipelining

· Can be thought of as symbolic loop unrolling

· May use loop-unrolling to figure out how to pipeline the loop

· Loop unrolling reduces the overhead of the loop

· the branch and counter update code

· but every time the inner unrolled loop still need be initiated

Software pipelining reduces the time when the loop is not running at peak speed to once per loop

· major advantage: consumes less code space

· In practice, compilation using software pipelining is quite difficult

the best performance can come from doing both

Global Code Scheduling

· Loop unrolling and s/w pipelining mainly work for basic blocks

· Global code scheduling: moving instructions across branches

· Aims to compact a code fragment with internal control structure into the shortest possible sequence that preserves the data and control dependences

· Requires estimates of the relative frequency of different paths

· shortest possible sequence = shortest sequence for the critical path

· Can not guarantee faster code

Two tasks

1. Find the common path

2. Move the assignments to B or C

Trace Scheduling – Critical Path Scheduling

Two steps:

· Trace Selection

· Trace profiling first

· Find likely sequence of basic blocks (trace) of (loop unrolled, statically predicted or profile predicted) long sequence of straight-line code

· Unwinding frequent path

· Trace Compaction

· Squeeze trace into few VLIW instructions

· Need bookkeeping code in case prediction is wrong

· If an instruction can be moved and thereby make the trace execute faster, it is moved

· Compiler undoes bad guess (discards values in registers)

· Subtle compiler bugs mean wrong answer vs. poorer performance; no hardware interlocks

· Assume it’s the inner loop and the likely path

· Unwind it four times

· Require the compiler to generate and trace the compensation code

Superblocks

· superblock: single entry point but allow multiple exits

· Compacting a superblock is much easier than compacting a trace

· Tail duplication

· Create a separate block that corresponds to the portion of the trace after the entry

· Superblock approach vs. trace-based approach

· Reduce the complexity of bookkeeping and scheduling, but may enlarge code size

· Both may be most appropriate when other techniques fail

Hardware Support for Exposing More Parallelism at Compiler Time

Conditional or Predicated Instructions

· Most common form is move

· Other variants

· Conditional loads and stores

· ALPHA, MIPS, SPARC, PowerPC, and P6 all have simple conditional moves

· IA_64 supports full predication for all instructions

· Effect is to eliminating simple branches

· Moves dependence resolution point from early in the pipe (branch resolution) to late in the pipe (register write) forwarding…is more possible

· Also changes a control dependence into a data dependence

· Net win since in global scheduling the control dependence fence is the key limiting complexity

Conditional Instruction in SuperScalar

First slot(Mem) Second slot (ALU)

LW R1,40(R2) ADD R3, R4, R5

ADD R6, R3, R7

BEQZ R10, L

LW R8, 20(R10)

LW R9, 0(R8)

· Waste a memory operation slot in the 2nd cycle

· data dependence stall if not taken

First slot(Mem) Second slot (ALU)

LW R1,40(R2) ADD R3, R4, R5

LWC R8,20(R10),R10 ADD R6, R3, R7

BEQZ R10, L

LW R9, 0(R8)

Condition Instruction Limitations

· Precise Exceptions

· If an exception happens prior to conditional evaluation, it must be carried through the pipe

· Simple for register accesses but consider a memory protection violation or a page fault

· Long conditional sequences – If-then with a big then body

· If the task to be done is complex, better to evaluate the condition once and then do the big block

· Conditional instructions are most useful when the condition can be evaluated early

· If data dependence in determining the condition help less

· Wasted resource

· Conditional instructions consume real resources

· Tends to work well in the superscalar case

· Our simple 2-way model Even if no conditional instruction, other resource is wasted anyway

· Cycle-time or CPI Issues

· Conditional instructions are more complex

· Danger is that they may consume more cycles or a longer cycle time

· Note that the utility is mainly to correct short control flaws

· Hence use may not be for the common case

· Things better not slow down for the real common case to support the uncommon case

· How to make sure that a mis-predicted speculated instruction (SI) can not cause an exception

· Four methods

· HW and OS cooperatively ignore exceptions for SI

· SI that never raise exceptions are used, and checks are introduced to determine when an exception should occur

· Poison bits are attached to the result registers written by SI when SI cause exceptions. The poison bits cause a fault when a normal instruction attempts to use the register

· A mechanism to indicate that an instruction is speculative, and HW buffers the instruction result until it is certain that the instruction is no longer speculative

Exception Types

· Indicate a program error and normally cause termination

· Memory protection violation…

· Should not be handled for SI when miss prediction

· Exceptions cannot be taken until we know the instruction is no longer speculative

· Handled and normally resumed

· Page fault…

· Can be handled for SI just if they are normal instructions

· Only have negative performance effect when mis prediction

Poison Bits

· Track exceptions as they occur but postpones any terminating exception until a value is actually used.

· Incorrect programs that caused termination without speculation will still cause exceptions when instructions are speculated.

· Poison bit for every register. A bit to indicate SI

· The poison bit of a destination register is set when SI results in a terminating exception.

· All other exceptions are handled immediately

A SI uses a poisoned register dest-reg is

LD R1, 0(R3) ; load A

sLDR14, 0(R2) ; spec-lw B. If exception R14 poisoned

BEQZ R1, L3 ; other bran.

DADDIR14, R1, #4 ; else

L3: SD R14, 0(R3) ; store A. R14 poisoned SD fault

· If sLD generates a terminating exception, the poison bit of R14 will be turned on. When SD occurs, it will raise an exception if the poison bit for R14 is on.

HW Support for Memory Reference Speculation

· Try to Move loads across stores any address conflict?

· HW Use a special instruction to check for address conflicts

· The special instruction is left at the original location of the load instruction (act like a guardian), and the load is moved up across one or more stores

· When a speculated load is executed, HW saves the address of the accessed memory location

· To speculate extensively, we must be able to disambiguate memory reference easy for HW (Tomasulo)

· HW speculation works better when control flow is unpredictable, and when HW branch prediction is superior to SW branch prediction done at compiler time

· Misprediction rate 16%/10% for 4 major integer SPEC92 SW/HW

· HW speculation maintains a completely precise exception model for SI

HW speculation does not require compensation or bookkeeping code, needed by ambitious SW speculation.

· HW speculation with dynamic scheduling does not require different code sequences to achieve good performance for different implementation of an architecture

· HW speculation require complex and additional HW resources

· Some designers have tried to combine the dynamic and compiler-based approaches to achieve the best of each

HW Versus SW Speculation Mechanisms

· To speculate extensively, we must be able to disambiguate memory reference easy for HW (Tomasulo)

· HW speculation works better when control flow is unpredictable, and when HW branch prediction is superior to SW branch prediction done at compiler time

· Misprediction rate 16%/10% for 4 major integer SPEC92 SW/HW

· HW speculation maintains a completely precise exception model for SI

· HW speculation does not require compensation or bookkeeping code, needed by ambitious SW speculation

· HW speculation with dynamic scheduling does not require different code sequences to achieve good performance for different implementation of an architecture

· HW speculation require complex and additional HW resources

· Some designers have tried to combine the dynamic and compiler-based approaches to achieve the best of each.

Intel IA-64 and Itanium Processor

Designed to benefit VLIW approach

IA-64 Register Model

· 128 64-bit GPR (65 bits actually)

· 128 82-bit floating-point registers

· two extra exponent bits over the standard 80-bit IEEE format

· 64 1-bit predicate register

· 8 64-bit branch registers, used for indirect branches

· a variety of registers used for system control, etc.

· other supports:

· register stack frame: like register window in SPARC

· current frame pointer (CFM)

· register stack engine

Two concepts to achieve the benefits of implicit parallelism and ease of instruction decode

· instruction group: a sequence of consecutive instructions without register data dependences

· instructions in the group can be executed in parallel

· arbitrarily long, but the compiler explicitly indicates the boundary by placing a stop

· bundle: fixed formatting of multiple instructions (3)

· IA-64 instructions are encoded in bundles

· 128 bits wide: 5-bit template field and three 41-bit instructions

· the template field describes the presence of stops andspecifies types of execution units for each instruction

Predication and Speculation Support

Traditional arch. with branch barrier

instr 1

instr 2

:

br

ld r1=…

use …=r1

Itanium Support for Explicit Parallelism

ld.s r1=…

instr 1

instr 2

br

chk.s r1

use …=r1

Limits on ILP

· Conflicting studies of amount

· Benchmarks (vectorized Fortran FP 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?

· Intel MMX, SSE (Streaming SIMD Extensions): 64 bit ints

· Intel SSE2: 128 bit, including 2 64-bit Fl. Pt. per clock

· Motorola AltiVec: 128 bit ints and FPs

· Supersparc Multimedia ops, etc.

· Advances in compiler technology + significantly new and different hardware techniques may be able to overcome limitations assumed in studies

· However, unlikely such advances when coupled with realistic hardware will overcome these limits in near future

· Initial HW Model here; MIPS compilers.

Assumptions for ideal/perfect machine to start:

1. Register renaming – infinite virtual registers => all register WAW & WAR hazards are avoided

2. Branch prediction – perfect; no miss predictions

3. Jump prediction – all jumps perfectly predicted (returns, case statements)2 & 3 no control dependencies; perfect speculation & an unbounded buffer of instructions available

4. Memory-address alias analysis – addresses known & a load can be moved before a store provided addresses not equal; 1&4 eliminates all but RAW

Also: perfect caches; 1 cycle latency for all instructions (FP *,/); unlimited instructions issued/clock cycle

Model

Power 5

Instructions Issued per clock

Infinite

4

Instruction Window Size

Infinite

200

Renaming Registers

Infinite

48 integer + 40 Fl. Pt.

Branch Prediction

Perfect

2% to 6% misprediction

(Tournament Branch Predictor)

Cache

Perfect

64KI, 32KD, 1.92MB L2, 36 MB L3

Upper Limit to ILP: Ideal Machine

Programs

Instruction Issues per cycle

0

20

40

60

80

100

120

140

160

gcc

espresso

li

fpppp

doducd

tomcatv

54.8

62.6

17.9

75.2

118.7

150.1