Instruction-Level Parallel Processing: History, Overview, and Perspective

Rau, B. Ramakrishna; Fisher, Joseph A.

doi:10.1007/978-1-4615-3200-2_3

Cited by 36 publications

(34 citation statements)

References 146 publications

(224 reference statements)

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…First, like VLIW architectures [Rau and Fisher 1993], the placement of instructions onto ALUs is encoded into the instruction stream. This mechanism eliminates the need for hardware placement algorithms and reduces the burden on bypassing networks as operation destinations are encoded in the instructions.…”

Section: Related Workmentioning

confidence: 99%

Trips

Sankaralingam

Nagarajan

Liu

et al. 2004

ACM Trans. Archit. Code Optim.

View full text Add to dashboard Cite

This paper describes the polymorphous TRIPS architecture that can be configured for different granularities and types of parallelism. The TRIPS architecture is the first in a class of post-RISC, dataflow-like instruction sets called explicit data-graph execution (EDGE). This EDGE ISA is coupled with hardware mechanisms that enable the processing cores and the on-chip memory system to be configured and combined in different modes for instruction, data, or thread-level parallelism.To adapt to small and large-grain concurrency, the TRIPS architecture prototype contains two outof-order, 16-wide-issue grid processor cores, which can be partitioned when easily extractable finegrained parallelism exists. This approach to polymorphism provides better performance across a wide range of application types than an approach in which many small processors are aggregated to run workloads with irregular parallelism. Our results show that high performance can be obtained in each of the three modes-ILP, TLP, and DLP-demonstrating the viability of the polymorphous coarse-grained approach for future microprocessors.

show abstract

Section: Related Workmentioning

confidence: 99%

Trips

Sankaralingam

Nagarajan

Liu

et al. 2004

ACM Trans. Archit. Code Optim.

View full text Add to dashboard Cite

show abstract

“…VLIW architecture, when viewed as a contractual interface between the class of programs and the set of processor implementations, is basically an Independence Architecture [16]. It specifies a set of operations that are guaranteed to be mutually independent and can be issued simultaneously by the issue hardware without any checks.…”

Section: Extended Split-issue Mechanismmentioning

confidence: 99%

Extended Split-Issue

Iyer

Srinivasan

Jacob

2004

SIGARCH Comput. Archit. News

View full text Add to dashboard Cite

VLIW architecture based DSPs have become widespread due to the combined benefits of simple hardware and compiler-extracted instruction-level parallelism. However, the VLIW instruction set architecture and its hardware implementation are tightly coupled, especially so for Non-Unit Assumed Latency (NUAL) VLIWs. The problem of object code compatibility across processors having different numbers of functional units or hardware latencies has been the Achilles' heel of this otherwise powerful architecture. In this paper, we propose eXtended Split-Issue (XSI), a novel mechanism that breaks the instruction packet syntax of an NUAL VLIW compiler without violating the dataflow dependences. XSI provides a designer the freedom of disassociating the hardware implementation of the NUAL VLIW processor from the instruction set architecture. Further, we investigate fairly radical (in the context of VLIW) changes to the hardware-like removing an adder, adding a multiplier, and incorporating simultaneous multithreading (SMT)-to show that our technique works for a variety of hardware configurations without compromising on performance. The technique can be used in both single-threaded and multi-threaded architectures to achieve a level of flexibility heretofore unavailable in the VLIW arena.

show abstract

“…The solution to this problem is software pipelining [22,23]. Software pipelining rearranges a loop such that successive iterations of the original loop are executed in parallel.…”

Section: Pipelined Interpretersmentioning

confidence: 99%

A code compression system based on pipelined interpreters

Hoogerbrugge

Augusteijn

Trum

et al. 1999

Softw: Pract. Exper.

View full text Add to dashboard Cite

This paper describes a system for compressed code generation. The code of applications is partioned into time-critical and non-time-critical code. Critical code is compiled to native code, and non-critical code is compiled to a very dense virtual instruction set which is executed on a highly optimized interpreter. The system employs dictionary-based compression by means of superinstructions which correspond to patterns of frequently used base instructions. The code compression system is designed for the Philips TriMedia VLIW processor. The interpreter is pipelined to achieve a high interpretation speed. The pipeline consists of three stages: fetch, decode, and execute. While one instruction is being executed, the next instruction is decoded, and the next one after that is fetched from memory. On a TriMedia VLIW with a load latency of three cycles and a jump latency of four cycles, the interpreter achieves a peak performance of four cycles per instruction and a sustained performance of 6.27 cycles per instruction. Experiments are described that demonstrate the compression quality of the system and the execution speed of the pipelined interpreter; these were found to be about five times more compact than native TriMedia code and a slowdown of about eight times, respectively.

show abstract

Instruction-Level Parallel Processing: History, Overview, and Perspective

Cited by 36 publications

References 146 publications

Trips

Trips

Extended Split-Issue

A code compression system based on pipelined interpreters

Contact Info

Product

Resources

About