17
Lecture 3: Evolution of the Uniprocessor SIMD VLIW DAE HPS Data Flow

Lecture 3: Evolution of the Uniprocessor

Embed Size (px)

DESCRIPTION

Lecture 3: Evolution of the Uniprocessor. SIMD VLIW DAE HPS Data Flow. The HPS Paradigm. Incorporated the following: Aggressive branch prediction Speculative execution Wide issue Out-of-order execution In-order retirement First published in Micro-18 (1985) - PowerPoint PPT Presentation

Citation preview

Page 1: Lecture 3: Evolution of the Uniprocessor

Lecture 3: Evolution of the Uniprocessor

• SIMD

• VLIW

• DAE

• HPS

• Data Flow

Page 2: Lecture 3: Evolution of the Uniprocessor
Page 3: Lecture 3: Evolution of the Uniprocessor
Page 4: Lecture 3: Evolution of the Uniprocessor
Page 5: Lecture 3: Evolution of the Uniprocessor
Page 6: Lecture 3: Evolution of the Uniprocessor

The HPS Paradigm

• Incorporated the following:– Aggressive branch prediction– Speculative execution– Wide issue– Out-of-order execution– In-order retirement

• First published in Micro-18 (1985)– Patt, Hwu, Shebanow: Introduction to HPS– Patt, Melvin, Hwu, Shebanow: Critical issues

Page 7: Lecture 3: Evolution of the Uniprocessor
Page 8: Lecture 3: Evolution of the Uniprocessor
Page 9: Lecture 3: Evolution of the Uniprocessor
Page 10: Lecture 3: Evolution of the Uniprocessor
Page 11: Lecture 3: Evolution of the Uniprocessor

The final flexibility: Data Flow

Page 12: Lecture 3: Evolution of the Uniprocessor
Page 13: Lecture 3: Evolution of the Uniprocessor
Page 14: Lecture 3: Evolution of the Uniprocessor
Page 15: Lecture 3: Evolution of the Uniprocessor

Characteristics of Data Flow

• Data Driven execution of inst-level Graphical code– Nodes are operators– Arcs are I/O

• Only REAL dependencies constrain processing– Anti-dependencies don’t (write-after-read)– Output dependencies don’t (write-after-write)– NO sequential I-stream (No program counter)

• Operations execute ASYNCHRONOUSLY• Instructions do not reference memory

– (at least memory as we understand it)

• Execution is triggered by presence of data

Page 16: Lecture 3: Evolution of the Uniprocessor

• Why Data Flow?– Irregular Parallelism– Only real dependencies constrain

• Anti-dependencies don’t

• Sequential I-stream doesn’t (No Program Counter)

– Asynchronous (NOT in the sense of un-clocked)

• Why NOT Data Flow?– In one word: too much architectural state

Page 17: Lecture 3: Evolution of the Uniprocessor

Specific Problems with Data Flow

• Code bloat (everything is explicit)• Code debug (asynchronous, non-deterministic flow)• Interrupt handling (providing a consistent state)• Machine diagnosis (trouble-shooting design errors)• Recursion• Large data structures• Node table overflow (cost of CAM is high)• Performance caveats

– Array copy operations– Long latencies– Network (bypass paths) congestion