Browse Prior Art Database

Concurrent Execution of Multi Cycle Instructions with Resource Limitations

IP.com Disclosure Number: IPCOM000117913D
Original Publication Date: 1996-Jul-01
Included in the Prior Art Database: 2005-Mar-31
Document File: 2 page(s) / 59K

Publishing Venue

IBM

Related People

Goulet, M: AUTHOR [+4]

Abstract

Disclosed is a mechanism to better utilize multiple execution engines in a functional unit with resource limitations. Stalling instructions within the engines when limited resources are unavailable provides higher performance than restricting concurrent use of the multiple engines.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 81% of the total text.

Concurrent Execution of Multi Cycle Instructions with Resource Limitations

      Disclosed is a mechanism to better utilize multiple execution
engines in a functional unit with resource limitations.  Stalling
instructions within the engines when limited resources are
unavailable provides higher performance than restricting concurrent
use of the multiple engines.

      Superscalar processors are composed of multiple functional
units; these multiple functional units may be composed of specialized
execution engines.  But, as the number of engines increase,
bottlenecks develop in getting instructions to the engines and in
getting results from those engines to rename buffers or register
files.  These problems occur for engines that take multiple cycles to
compute results.  The problem becomes hard to solve if the execution
engines have different or varying latencies; indeterminate latencies
complicate it further.

      One way to alleviate these bottlenecks is to restrict the
number of execution engines that can be working on instructions at
one time (Fig. 1).  However, imposing this restriction reduces
performance; engines now sit idle when they could be doing useful
work.

      To best optimize performance of multiple execution engines, it
would be better to only restrict the activities at the bottlenecks,
not at intermediate points (Fig. 2).  That is, restrict the number of
instructions that can go to the execution engines at one time, and
restrict th...