Transcript Reviving Accumulator Architecture for High ILP Implementation Peter Hsu, Ph.D.

Reviving Accumulator Architecture
for High ILP Implementation
Peter Hsu, Ph.D.
Chief Architect
Microprocessor Development
Toshiba America Electronics Components, Inc.
Created 14 May 2001 at the University of Wisconsin in Madison
Toshiba
Introduction

What limits ILP?
1. Knowing where to fetch instructions
2. Cumulative delay of dependent operations

Proposal
1. Predicated execution
2. Accumulator architecture

Inspired by
– Semour Cray’s original Cray-2 proposal (circa 1975)
– Guri’s Multiscalar ideas (circa 1980)
Reviving Accumulator Architecture for High ILP Implementation
2
Compiler
RISC Instructions
A:
B:
C:
D:
E:
F:
G:
H:
I:
addiu
sw
jal
addiu
sw
sw
bne
lw
j
lw
addu
jal
lw
lw
addiu
jr
lw
sltu
beq
addu
addiu
syscall
STRING Instructions
r29,r29,0xffffffe8
r31,0x0010(r29)
0x00411570 [B]
r29,r29,0xffffffe8
r31,0x0014(r29)
r16,0x0010(r29)
r4,r0,0x004115a0 [D]
r2,0xffff82b0(r28)
0x004115d8 [E]
r16,0xffff82b0(r28)
r4,r16,r4
0x00411700 [F]
r31,0x0014(r29)
r16,0x0010(r29)
r29,r29,0x0018
r31
r2,0xffff82b4(r28)
r1,r4,r2
r1,r0,0x00411720 [H]
r4,r0,r2
r2,r0,0x0011
0x0
r4  t67
#0x40e918  t70
predicate
r29 add(-8) data(r31)  store.w
r29 add(-28) data(t70)  store.w
r29 add(-32) data(r16)  store.w
#17  r2
?(!t67)
#0x4115b8  r31
?(!t67)
r28 add(-32080) lw  r2
?( t67)
r28 add(-32080) lw  r16
?(!t67)
r28 add(-32076) lw  t69
r29 add(-28) lw  r31
?( t67)
r28 add(-32080) lw add(r4) lt(t69)  t68
r28 add(-32080) lw add(r4) lt(t69)  r1 ?(!t67)
r28 add(-32080) lw add(r4)  r4 ?( t68 & !t67)
t69  r4
?(!t68 & !t67)
r29  t71
r29 add(-32) lw  r16
?( t67)
t71 add(-48)  r29
?(!t67)
t71 add(-24)  r29
?( t67)
#0  trap
?(!t67)
t71 add(-28) lw  jump
?( t67)
Reviving Accumulator Architecture for High ILP Implementation
3
Hardware
Processing Element
I$
D$
D$
branch
targets
update
queues
I$
Reviving Accumulator Architecture for High ILP Implementation
D$
D$
I$
– Register or memory
write (neighbor)
– Branch target address
(broadcast)
– Cache miss (global) level 2 cache
D$
Wires
processing
element
D$

Executes one string
Own ALU, accumulator
Copy of register file
Replicated I-, D-caches
Own gated clock tree
D$
D$
miss address
busI$
I$
–
–
–
–
–
I$
I$

cache miss refill bus
I$
4
Execution Profile
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
r4t67
#.. t70
3
r29 add(#)d(r31)store
4
r29 add(#)
5
r29 add(#)d(r16)
store
6
#17
?!t67 r2
7
#..
8
r28 add(#)ld.w
9
17
18
t69
add(#)ld.w
r31
?(t67)
add(#)ld.w
r28
String Number
16
r16
add(#)ld.w
r28
13
r2
?!t67
r29
12
15
?t67
add(#)ld.w
r28
11
14
?!t67 r31
r28
10
d(t70)store
add(r4)
add(#)ld.w
r28
lt(t69)r1
add(#) ld.w
t69
lt(t69)?!t67 t68
add(r4)
&t68 r4
add(r4)?!t67
?!t67
r29
&!t68r4
t71
r29
add(#)ld.w
t71
19
?t67
add(#) ?!t67 r29
t71
20
r16
add(#)?t67
t71
21
add(#)ld.w ?t67 jump
#0
Reviving Accumulator Architecture for High ILP Implementation
r29
?!t67trap
5
§
Preliminary Results

Number of strings (dynamic)
–  Number of RISC instructions

String length
– Average 3.5 operations (redundancy cost)

“Hyperblock”
– Average 15 strings
 Half as many taken branches as RISC
§
gcc, 30M instructions (truncated)
test-printf.c, 1.7M instructions
Reviving Accumulator Architecture for High ILP Implementation
6
Why Exciting?

Taken branch inhibits parallelism
– Processing more than one per cycle very difficult
• Need 1st target to look up 2nd predictor
– Causes instruction starvation
• Taken branch  15% all instructions (RISC)

More operations is good trade
– ALU  free
• But data movement  free!
– Target of not-taken branch is easy
• No side effects: just confirm
– Loads that hit in cache are cheap
• Duplicated loads can’t miss...
Reviving Accumulator Architecture for High ILP Implementation
7
Outline

Introduction
 Background
 Program Representation
 Hardware
 Detailed Example
 Summary & Conclusions
 Future Work
Reviving Accumulator Architecture for High ILP Implementation
8
Background

Predication  more operations  higher ILP
–
–
–
–
–

Joseph Fisher [1979 ]
Bob Rau [1982]
Peter Hsu [1986]
Wen-mei Hwu [1993]
many others...
Difficulty is implementation
– VLIW
• Bi-zillion ported register file, or crossbar
• All fabricated to-date have slow clock cycle...
– Superscalar
• Many functional units  numerous bypasses
Reviving Accumulator Architecture for High ILP Implementation
9
Program Representation

Requirements
– Dispatch multiple strings per cycle
 fixed size
– Compact (mitigate redundancy)
 variable size
Reviving Accumulator Architecture for High ILP Implementation
10
Program Representation
end

Requirements
header 4
– Dispatch multiple strings per cycle
header 3
 fixed size
dispatcher
scan
– Compact (mitigate redundancy)
 variable size

branch target label:
String
– Header (fixed size)
header 1
b
o
d
y
1
2
• Length of string body
• State to be updated
– Body (variable size)
• Different number of instructions
• Instructions also variable length
header 2
hyperblock
b
o
d
y
3
4
Reviving Accumulator Architecture for High ILP Implementation
11
Processing Element
cache miss refill bus

Register file
branch target
– One read port, one write port
– Cache hit  register read

ready?
Write updates
DATA
CACHE
– Register, memory values
propagate to future PE
– Taken branch broadcast target

PC
INSTR
CACHE
REG FILE
dispatch
Squash
– Propagate corrected value
A
• Own SRAM has old value

+
ALU
Instruction processing
– Totally serial
cache miss address bus
Reviving Accumulator Architecture for High ILP Implementation
12
Dependencies
end

header 4 parallel
length
header 3 addition
Header scan
– Every PE sees every header
• e.g. eight 16-bit in parallel
dispatcher
– Skips over preceeding strings
1. Extract states to be updated
– Register number
– Memory (no address yet)
– Program counter (no target yet)
header 1
branch target label:
1st string
no extra
delay
b
o
d
y
1
subsequent strings
delayed 1 cycle
2
hyperblock
b
o
d
y
3
2. Calculate instruction offset
– PE knows own “position”
– Sum lengths of previous strings
header 2
• Adder tree, like multiplier
Reviving Accumulator Architecture for High ILP Implementation
4
13
Physical Mapping
cache miss refill bus
cache miss refill bus
branch target
ready?
I$
+
D$
branch
targets
update
queues
I$
A
D$
dispatch
D$
REG FILE
I$
INSTR
CACHE
D$
DATA
CACHE
processing
element
I$
I$
PC
D$
D$
miss address
busI$
ALU
I$
cache miss address bus
D$
D$
I$
level 2 cache
Reviving Accumulator Architecture for High ILP Implementation
14
Execution Profile
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
r4t67
#.. t70
register write
propagation
3
r29 add(#)d(r31)store
4
r29 add(#)
5
r29 add(#)d(r16)
store
6
#17
?!t67 r2
7
#..
8
r28 add(#)ld.w
9
?t67
add(#)ld.w
r28
18
19
20
21
add(#)ld.w
r31
?(t67)
add(#)ld.w
r28
String Number
17
r16
t69
r28
13
16
?!t67
r29
12
15
r2
add(#)ld.w
11
14
store address
resolution
?!t67 r31
r28
10
d(t70)store
add(r4)
add(#)ld.w
r28
lt(t69)?!t67 t68
add(r4)
add(#) ld.w
t69
speculative
load
lt(t69)r1
&t68 r4
add(r4)?!t67
?!t67
r29
&!t68r4
t71
r29
add(#)ld.w
t71
ring (8 PE)
completed
?t67
add(#) ?!t67 r29
t71
non-speculative
load
Reviving Accumulator Architecture for High ILP Implementation
r16
add(#)?t67
t71
r29
add(#)ld.w ?t67 jump
#0
?!t67trap
15
Why Accumulator?

Motivations
– Cumulative execution latency limits achievable ILP
• Future strings waiting for forwarded value
– String mostly simple ALU operations
REG FILE
• Occasional memory load
– Carry-save arithmetic applicable
• Many-bit shifts not common
• Cache index need low-order address bits

A
ALU
Accumulator, one-address operand
– Fastest clock cycle, least extra latency
– Fewest wires (no bypass muxes)
– Same reasoning in 1950
Reviving Accumulator Architecture for High ILP Implementation
16
Achieving Fast Clock
PE own gated clock
D$
Branch broadcast
branch
targets
– Cache index ( 16bit)
I$
update
queues
Cache miss
– 2 clock period
– All PE caches same
I$
D$
D$
I$

D$
– Absorb PE-to-PE
clock skew
D$

processing
element
Update queues
D$

D$
D$
miss address
busI$
I$
– Faster flipflops
– Wait on one event
I$
I$

cache miss refill bus
I$
level 2 cache
Reviving Accumulator Architecture for High ILP Implementation
17
Summary

Explicitly Dependent Instructions
– Easy for compiler to detect (obvious)
– Easy for hardware to sequence (no choices)

Anonomous intermediate values
– No side effects (re-execute anytime)
– Predication unnecessary; exceptions at string edge

Memory read-write ordering
– Naturally speculate loads (thus initiating prefetch)
– PE remembers own load address, decides to re-execute

Unification of DSP and general purpose compute
– Higher-precision accumulation, streaming data
Reviving Accumulator Architecture for High ILP Implementation
18
What Next?

Simulator, port gcc
– 20% “dumb” strings just copy register

Code scheduler
– String order, in hyperblock
– Instruction order within string
• Predicates (“out-of-band” instructions in load “delay slot”)
• Associative arithmetic (late-arriving register values)

Performance analysis
– Still needs branch prediction, squashing, ...
– ILP vs. update propagation rate
– DSP, no L2 cache (multi-thread?), vectors, MMX

Good name!
Reviving Accumulator Architecture for High ILP Implementation
19