Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

Superscalar and Super Pipelined Processors

Download as pdf or txt
Download as pdf or txt
You are on page 1of 3

Superscalar and Super pipelined Processors

A scalar processor executes scalar instructions, that is instructions operating on


single quantity operands such as integers. As we have seen, the design of such a
processor may be pipelined where the staggered use of the pipeline can improve
instruction throughput. A superscalar processor is one which executes more than one
scalar instruction concurrently. This is achieved by having a number of independent
pipelines. A limited form of superscalar operation is present in processors that have,
for example, separate integer and floating point units. After the decode stage the
instructions are sent to the appropriate unit and can execute in parallel. True superscalar
operation can only be achieved by fetching a number of instructions simultaneously
and executing them simultaneously.

The objective of superscalar design is to improve performance by exploiting


instruction level parallelism in user programs. We might expect that doubling the
number of pipelines would double performance, but we have seen the problems caused
by pipeline hazards in a single pipeline and can see that this problem is much more
critical for superscalar processors and that some of the pipelines will be stalling. One
of the characteristics of RISC designs is that the processor has a simplified instruction
set architecture resulting in fewer data interdependencies. For this reason, virtually all
superscalar designs have been based on a RISC architecture. The superscalar degree is
low due to limited instruction parallelism that can be exploited in ordinary programs.
Instruction issue and completion policies are critical to superscalar processor
performance.
When instructions are issued (i.e. initiation of their execution in functional units) in
program order it is called in-order issue. When program order is violated, out-of-order
issue is being practiced.

When instructions must be completed (i.e. have altered register and/or memory) in
program order, it is called in-order completion, otherwise out-of-order completion
may result. In-order issue is easier to implement but may not yield the optimal
performance. Proper scheduling can avoid stalling the pipelines. A number of possible
scheduling policies are possible. In the examples below, the pipeline cycle is the
minimum time between consecutive exchanges between each stage of the pipeline.

In-Order Issue with In-Order Completion


Assume we have a superscalar pipeline capable of fetching and decoding two
instructions at a time. Let's say there are three separate functional units and that there
are two instances of the writeback pipeline stage. Let's say we have six instructions
with the following constraints:

I1 requires two cycles to execute. I3 and I4 conflict for the same functional unit. I5
depends on the value produced by I4. I5 and I6 conflict for a functional unit.
Instructions are only decoded up to the point of a dependency or resource conflict. No
additional instructions are decoded until the conflict is resolved. This means a
maximum of two instructions can be in the execute stage as later instructions have a
time dependency on earlier ones executing first.

You might also like