Browse Prior Art Database

Efficient Operation of the Fetch/Store Table

IP.com Disclosure Number: IPCOM000103936D
Original Publication Date: 1993-Feb-01
Included in the Prior Art Database: 2005-Mar-18
Document File: 2 page(s) / 97K

Publishing Venue

IBM

Related People

Ekanadham, K: AUTHOR [+3]

Abstract

For processors that are designed to perform out-of-sequence operand accesses, a means is devised to place fetches in a FETCH table and stores in a STORE table with resultant search operations. A similar TABLE structure can be used to monitor hazards that arise in MP versions of such machines. The means of efficiently searching these tables in the time-critical aspects of the overall design is now described.

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

Efficient Operation of the Fetch/Store Table

      For processors that are designed to perform out-of-sequence
operand accesses, a means is devised to place fetches in a FETCH
table and stores in a STORE table with resultant search operations.
A similar TABLE structure can be used to monitor hazards that arise
in MP versions of such machines.  The means of efficiently searching
these tables in the time-critical aspects of the overall design is
now described.

      The hashing of addresses to a list structure to determine if an
address compares to one of a set of existing addresses, or the linear
search of a list to make that determination, ignores aspects of the
machine design which can, with a high probability, offer a means of
expediting a search.

      Each access to a memory hierarchy in a virtual memory system
performs two lookup operations.  The first lookup is with respect to
a set of DLATs that convert the virtual address to a real address.
The second lookup operation is within a cache directory.  These
lookup operations have a common benefit as well as a common problem.
The benefit is that all accesses which share a common address, with
high probability, reference the same element of these directories and
thus indicative information can be associated with these entries in
these directories.  The common problem is that these entries can be
lost as a result of a miss which displaces the entry.

      For caches that are synonym free, the statement of sharing the
same directory entry can be made in an unequivocal manner and we
shall choose the cache directory entry as a means of maintaining
indicative information about the FETCH/STORE TABLE entries and allow
the information to survive a cache miss that displaces the directory
entry.

      The means of surviving a cache miss that displaces the
directory entry is to preserve this information within a second
table.  As future operand activity will cause the cache line to
return, the table called the FETCH/STORE INDICATOR TABLE (FSIT) will
be accessed in parallel with the miss and its information restored to
the cache  directory entry.  The same approach is possible for DLAT
misses.

      The implementation of the invention involves the determination
as to what indicative information hereafter referred to as the
information is to be associated with a cache line.  How the
information is to be created at the time of the access to the line,
how the information is to be removed when the access is pruned from
the table, and how the information is to survive a cache miss.  The
information is not strictly speaking part of the cache directory but
is referenced in parallel with the directory and referenced via the
positional index within the directory.  The information as maintained
in the FSIT will involve the real address o...