Browse Prior Art Database

Register Renaming on Arithmetic

IP.com Disclosure Number: IPCOM000110919D
Original Publication Date: 1994-Jan-01
Included in the Prior Art Database: 2005-Mar-26
Document File: 4 page(s) / 103K

Publishing Venue

IBM

Related People

Handlogten, GH: AUTHOR

Abstract

A method for eliminating the need to keep data in a store queue for a system using register renaming is disclosed.

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

Register Renaming on Arithmetic

      A method for eliminating the need to keep data in a store queue
for a system using register renaming is disclosed.

      Any write to a Floating Point Register (FPR) for any reason
will cause it to be associated with a new physical register
(remapped).  Now, since writing an FPR (whether initiated by loads or
arithmetic) never overwrites "live" data, instructions in the store
queue do not have to copy any data.  The data will remain unharmed in
the physical registers until the store is complete.  In addition, it
is now trivial to associate a result with a matching entry in the
store queue (there will be only one matching address).

      Instead of using one large general queue of available addresses
for all remapping, two smaller specialized queues are used; one only
for loads (called the Load Available Queue) and one only for
arithmetic (called the Arithmetic Available Queue).  This greatly
simplifies the logic since requests for addresses and returns of
addresses come from fewer sources.  It also reduces the number of
addresses that can be requested and returned each cycle.  In a system
where one arithmetic and one store instruction may be issued every
cycle, two "remappings" (of architected FPR to physical registers)
may be required each cycle.  With two dedicated queues, this is easy.

A similar benefit comes from the return mechanisms.  Four different
devices may return addresses each cycle but with two queues, each
queue will have to take at most two addresses per cycle.  Dedicating
the queues, as described, works out very well because the ratio of
Floating Point loads to Floating Point arithmetic that writes an FPR
is very close to 1:1.  Although separate queues are maintained for
loads and arithmetic, the physical registers are not restricted to
either one.  A physical register may be taken from the Load Available
Queue, used for a while, and then returned to the Arithmetic
Available Queue.

      The RS6000* already has a device and algorithm to ensure that
addresses removed from the Map Table by loads are not made available
too soon.  This piece can be used (with minor modifications) as the
dotted box above.

      A new device is required for ensuring that addresses removed
from the Map Table by arithmetic are not made available too soon.
The following instructions will help in the understanding of the
requirements of this device and algorithm.

   1.  X <- Y + Z   (this causes new entry in the Map Table for X)
        some instructions may be inserted here

   2.  Store X      (store of the FPR X from instruction 1)
        some instructions may be inserted here

   3.  L <- X + M   (X from instruction 1 is used...