Browse Prior Art Database

Data Restoration of an Addressable Array

IP.com Disclosure Number: IPCOM000108536D
Original Publication Date: 1992-Jun-01
Included in the Prior Art Database: 2005-Mar-22
Document File: 4 page(s) / 136K

Publishing Venue

IBM

Related People

Hicks, TN: AUTHOR

Abstract

One method of improving CPU performance is to decrease the cycle time. Many CPU designers do this by increasing the number of stages it takes to perform a function. This method is called pipelining. Super pipelined computers can have up to ten or more pipelined stages. What kills the performance of these machines is the occurrence of the branch instruction. The branch usually has to wait for the result of some instruction in the pipeline before it can decide on which path to take, either the 'taken' (target) or the 'not taken' (sequential) path. During this waiting the pipeline is completely emptied and even after the branch is decided it will be several cycles (depending on how long the pipeline is) before results start coming out of the CPU again.

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

Data Restoration of an Addressable Array

       One method of improving CPU performance is to decrease
the cycle time.  Many CPU designers do this by increasing the number
of stages it takes to perform a function. This method is called
pipelining.  Super pipelined computers can have up to ten or more
pipelined stages.  What kills the performance of these machines is
the occurrence of the branch instruction.  The branch usually has to
wait for the result of some instruction in the pipeline before it can
decide on which path to take, either the 'taken' (target) or the 'not
taken' (sequential) path.  During this waiting the pipeline is
completely emptied and even after the branch is decided it will be
several cycles (depending on how long the pipeline is) before results
start coming out of the CPU again.

      One method used in modern CPU designs is 'speculative
execution', executing instructions that may or may not have to be
executed.  The CPU would 'guess' which path the branch was going to
take.  This guess may be a very intelligent guess (as in a branch
history table) or very simple (as in always guess 'not taken').  Once
the guess is made, the CPU starts executing that path.  If the guess
is correct, there are no 'holes' or delays in the pipeline and
execution continues at full speed.  If the guess is incorrect, the
CPU starts executing the path that should have been taken and there
is no worse of a delay in execution than if the guess was not made.

      However, the instructions that should not have been executed
may have destroyed needed data.  For example, an add instruction that
should not have been executed will destroy the general-purpose
register (GPR) that it uses as its target.  In order to remedy this,
a mechanism must be in place to restore the GPRs effected.

      This article documents a mechanism for 'backing-out' or
restoring an addressable array used in modern CPUs for GPR or FPR
(floating-point register) storage.

      Fig. 1 shows a GPR array and the restore mechanism disclosed.
In restoring the array, only two things must be remembered: 1) the
data that was destroyed, and 2) where the data was located.  Both of
these are stored in the 'restore array'.  The restore array contains
both the data and the address it came from in one addressable
element.  This array must have the same number of write ports as the
GPR array has read ports in order to save all of the data coming out
of the GPR array each cycle.

      When speculative execution begins, the 'restore state machi...