Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!rutgers!dayton!umn-cs!alaska!pww
From: pww@alaska.cray.com (Paul Wells)
Newsgroups: comp.arch
Subject: Re: Double-bit errors and ECC memory
Message-ID: <870@alaska.cray.com>
Date: Fri, 25-Sep-87 19:47:54 EDT
Article-I.D.: alaska.870
Posted: Fri Sep 25 19:47:54 1987
Date-Received: Wed, 7-Oct-87 05:43:01 EDT
References: <686@obiwan.UUCP>, <8637@utzoo.UUCP> <8638@utzoo.UUCP>
Organization: Cray Research, Inc., Mendota Heights, MN
Lines: 11

In article <8638@utzoo.UUCP>, henry@utzoo.UUCP (Henry Spencer) writes:
> In a similar vein...  We now have machines that do TLB loading in software
> (e.g. MIPSCo) and even an occasional machine that does cache loading in
> software (Cheriton's MMUless virtual-address cache).  Has anybody thought
> about doing the correction (as opposed to detection) part of ECC in software?

Depends on what you mean by "correction".  The machines I'm familiar with do
perform correction in software -- in the sense of writing the corrected word
back to fix soft errors.  However, if you mean actually decoding the syndrome 
bits to determine which bit has been flipped, this seems impractical.  What
happens if the error is in the code that corrects errors?