Browse Prior Art Database

Restoring Conditional Stores to Caches And Memory

IP.com Disclosure Number: IPCOM000101547D
Original Publication Date: 1990-Aug-01
Included in the Prior Art Database: 2005-Mar-16
Document File: 2 page(s) / 108K

Publishing Venue

IBM

Related People

Liu, L: AUTHOR

Abstract

In some cache design, stores may be done on conditional basis. That is, a store into cache may be put away into arrays early before the validity of such a store is justified. Such a store with question on validity will be called a Conditional Store. However, in case such a store is found invalid later on, proper actions should be taken to maintain consistent data image in the cache. For a store-thru cache, such a contaminated line could simply be invalidated, with extra cache miss overhead for subsequent accesses. Generally speaking, it would be beneficial to be able to restore the cache contents from an invalid store putaway. This invention provides such a mechanism.

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

Restoring Conditional Stores to Caches And Memory

       In some cache design, stores may be done on conditional
basis.  That is, a store into cache may be put away into arrays early
before the validity of such a store is justified.  Such a store with
question on validity will be called a Conditional Store.  However, in
case such a store is found invalid later on, proper actions should be
taken to maintain consistent data image in the cache.  For a
store-thru cache, such a contaminated line could simply be
invalidated, with extra cache miss overhead for subsequent accesses.
Generally speaking, it would be beneficial to be able to restore the
cache contents from an invalid store putaway.  This invention
provides such a mechanism.

      For illustration, first consider a store-in cache design in
which individual fetch and putaway is at the granularity of
doubleword (DW).   Furthermore, ECC (Error Correcting Code) is
generated on DW basis for error detection and correction.  A general
cache store putaway to a cache line involves three steps:
      Step 1 - The DW is read out of the array to merge with
     the store requested (e.g., a partial store to a byte).
      Step 2 - The ECC bits are generated for the merged DW.
      Step 3 - The merged DW, together with generated ECC, is
     put back to the array to complete the store putaway.

      A set of DW registers maintained by the cache array control is
proposed.  Call them OC-registers (where OC stands for Old Content).
During Step 1, especially when uncertainty on the store validity is
involved, the old DW content (together with the ECC bits) read out is
copied into an OC-register.  The conditional store putaway should be
blocked (delayed) properly if none of the OC-registers is free for
its backup.  If invalidity is discovered for a conditional store
putaway, the associated OC-register content is restored into
associated cache array position to complete the backup process.  On
the other hand, if a conditional store putaway is verified as valid,
the associated OC- register may be freed for other use.  When a DW in
a cache line is still potentially dirty (e.g., when recorded in an
OC-register), any subsequent access (fetch or store) to it will
either be blocked (until the condition is cleared) or be treated as
conditional itself (subject to possible cancellation later on).
Similarly, during remote-access cross-interrogate situation in
multiprocessor (MP) design, the cache control should make sure to
properly resolve uncertainty of relevant conditional stores so as not
to damage architectural consistency of data.

      For certain cache designs (e.g., store-thru caches) there may
not be the need for ECC generation (Step 2).  In such a design stores
can be putaway into arra...