1 / 17

Lecture 3: Evolution of the Uniprocessor

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)

ann-hopkins
Download Presentation

Lecture 3: Evolution of the Uniprocessor

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Lecture 3: Evolution of the Uniprocessor • SIMD • VLIW • DAE • HPS • Data Flow

  2. 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

  3. The final flexibility: Data Flow

  4. 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

  5. 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

  6. 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

More Related