Browse Prior Art Database

Vector Register Allocation

IP.com Disclosure Number: IPCOM000100439D
Original Publication Date: 1990-Apr-01
Included in the Prior Art Database: 2005-Mar-15
Document File: 3 page(s) / 88K

Publishing Venue

IBM

Related People

Fletcher, RP: AUTHOR [+2]

Abstract

From a performance point of view it is desirable to allow vector instructions the freedom to execute out of sequence with other vector or scalar instructions. The difficulty arises when a later instruction changes the contents of an architected facility, e.g., a vector register, and an earlier instruction does not complete. This requires the changed facility to be restored to the old contents.

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

Vector Register Allocation

       From a performance point of view it is desirable to allow
vector instructions the freedom to execute out of sequence with other
vector or scalar instructions.  The difficulty arises when a later
instruction changes the contents of an architected facility, e.g., a
vector register, and an earlier instruction does not complete.  This
requires the changed facility to be restored to the old contents.

      One way to accomplish this "backing out" process is to assign a
temporary vector register to receive the new results.  This register
can then be declared official, contingent on all previous vector and
scalar instructions completing correcting, or simply ignored in the
event a previous vector instruction fails to complete correctly.

      The problem in assigning a temporary vector register is to
allow for mask operation, short vectors, interrupts, etc. In all
these situations many elements of the temporary register may never
receive new data.  This requires copying the original data elements
into the new temporary elements locations.

      In the figure, a vector instruction 1 is decoded and the two
source (VR2, VR3) and one destination (VR1) vector register addresses
are used to address a vector register address table (VRA) 2.  The VRA
2 provides a mapping function identifying the current location of the
vector registers VR1, VR2 and VR3 in the V Reg array 3.  The V Reg
array 3 has more vector register locations than are architected.  As
an example, if one assumes that a certain vector architecture
specifies up to 16 vector registers one might make the V Reg array
large enough to hold 17, or 18 or any larger number of vector
registers.  The extra registers can be used to hold temporary
results.  The architected register locations are kept track of by the
Architected Vector Register (AVR) table 4.  All unassigned V Reg 3
locations are kept in the Next Available Space (NAS) table 5.

  ...