Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Rename Recovery on Allocate

IP.com Disclosure Number: IPCOM000117745D
Original Publication Date: 1996-May-01
Included in the Prior Art Database: 2005-Mar-31
Document File: 4 page(s) / 126K

Publishing Venue

IBM

Related People

Hoy, TA: AUTHOR [+2]

Abstract

Rename resources that are allocated along a mispredicted path must be recovered for re-use later by the processor. This generally involves marking each resource with an ID that can represent a thread of execution in a program. The ID of a mispredicted path is then compared against the ID of every resource in the machine to determine if that resource can be recovered. This process requires a large number of comparators and may require duplication of information already stored elsewhere in the machine.

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

Rename Recovery on Allocate

      Rename resources that are allocated along a mispredicted path
must be recovered for re-use later by the processor.  This generally
involves marking each resource with an ID that can represent a thread
of execution in a program.  The ID of a mispredicted path is then
compared against the ID of every resource in the machine to determine
if that resource can be recovered.  This process requires a large
number of comparators and may require duplication of information
already stored elsewhere in the machine.

      When an instruction is dispatched, it is allocated an entry in
the completion buffer.  The completion buffer enforces in-order
completion of instructions in a machine.  Information about an
instruction and how it affects the architected state of the machine
is contained in a completion buffer entry.

      Three pieces of information that are written into the
completion buffer at dispatch time are important to the rename
recovery on allocate method.  First, the completion buffer entry
contains a flag that indicates whether the instruction writes an
architected GPR ("Write GPR" field).  Second, the entry contains the
logical GPR that will be written ("Logical GPR" field).  Third, the
entry contains the physical rename that has been allocated to that
architected register ("Physical Rename" field).  The Figure shows the
relevant fields of a completion buffer for a hypothetical piece of
code.

      The allocate pointer represents the first location in the
circular completion buffer that is available to be written with new
information.  The obsolete pointer represents the oldest instruction
in the machine.  When the allocate and the obsolete pointers are both
pointing to the same entry, this can represent either an empty
completion buffer or a full completion buffer.  An extra state
variable indicates which of these conditions is true.

      When the obsolete pointer reaches an instruction on the correct
path that has finished execution, the architected state of the
machine is updated with the result of the instruction.  Any renames
associated with this instruction are passed to the free logic.  At
the same time, the "Write GPR" field in the completion buffer entry
is reset.  This is done to differentiate between a committed
instruction and one that is orphaned on a mispredicted path.  All
other fields for this completion buffer entry remain unchanged.  This
completion buffer entry is now empty and can be reallocated when the
allocate pointer reaches the entry.  For the example in the Figure,
the add instruction in completion buffer entry 0 and the load
instruction in completion buffer entry 1 have been obsoleted, and the
obsolete pointer signifies that the load instruction in completion
buffer entry 2 is the next to obsolete.

      A different scenario happens for instructions that are on a
mispredicted path.  When a branch is resolved to be mispredicted, the
a...