radu teodorescu and josep torrellas university of...

The Design Complexity of Program Undo Support in a General Purpose

Processor

Radu Teodorescu and Josep Torrellas

University of Illinois at Urbana-Champaignhttp://iacoma.cs.uiuc.edu

Radu Teodorescu - University of Illinois Design Complexity of Program Undo

Speculative execution over large code sections

Rollback/re-play of program execution

Very low overhead

Speculation exposed to the software

Safe Code

Begin Spec

Safe Code

End Spec

Processor withprogram undo support

2

Safe Code

Safe Code

Speculative code

Begin Spec

End SpecEnd Spec

Safe

Speculative

Some Code


Applications of program undo

Safety net for speculating over:

correctness of aggressive optimizations:

thread level speculation, value prediction, speculative synchronization

system reliability:

software - primitive for software debugging

3


How complex is program undo support?

Determined the hardware needed

Implemented it in a simple processor

Prototyped it using FPGA technology

Estimated complexity using three metrics:

Hardware overhead, development time, VHDL code size

4


Implementation of program undo support

5

CPU

RF CKPT

Data Cache

Save/restore processor state, buffer speculative data, control transitions:

Memory

1. Register checkpointing and restoration

2. Data cache that buffers speculative data

3. Instructions enable/disable speculation on-the-fly

Safe

Speculative


Register checkpointing

Beginning of the speculative section

RF saved into a Shadow RF

PC, state registers are saved

End of speculative section

Commit: discard checkpoint

Rollback: restore RF & PC

6

IDLE

CHECKPOINT ROLLBACK

RESTORE


Data cache extensions

Holds both speculative and non-speculative data

Speculative lines will not be evicted to memory

Cache walk state machine:

Commit: merge lines

Rollback: invalidate speculative lines

7

Data Cache

0 1

0 1

Memory

IDLE

WALK RESTORE

Safe

Speculative


Software control

Give the compiler control over speculative execution

Added control instructions:

Begin speculation

End speculation (commit or rollback)

We use SPARC’s special access load

LDA [r0] code, r1

8


Hardware prototype

LEON2 - SPARC V8 compliant processor

In-order, single issue, 5-stage pipeline

Windowed register file

L1 instruction and data caches

Synthesizable, open source VHDL code

Fully functional, runs Linux embedded

9


System deployment

10

Processor Image

Control App.

I/O Terminal

Binaries

PCI

COM

JTAG


Evaluating design complexity

Hardware overhead, development time, VHDL code size

Major components:

register checkpointing

speculative cache

software control

Comparison: write-back cache controller

11


Hardware overhead

12

Avg. 4.5% overhead

0

1000

2000

3000

4000

5000

6000

7000

8000

9000

4KB 8KB 16KB 32KB 64KBData cache size

CLBs

softwarecontrolspeculativecacheregistercheckpointingwrite backextensionsbaselineprocessor


Development time

13

0

100

200

300

400

500

600

700

800

900

WB CacheController

SpeculativeCache

RegisterCheckpointing

SoftwareControl

Tim

e (m

an-h

ours

)

Testing

Implementation

Design


Lines of code

14

0

500

1000

1500

2000

2500

3000

3500

Data CacheController

Pipeline

Lin

es

of

VH

DL

co

de

Software controlSpeculative cacheRegister checkpointingWrite back extensionsBaseline unit

14.5%

7.5%


Conclusions

Program undo support is reasonably easy to implement

Complexity similar to adding write-back support to a write-through cache controller

Qualifying factor:

Relatively simple processor

15


Thank you!

16

Short demo and questions...

radu teodorescu and josep torrellas university of...

Documents