Path: utzoo!attcan!uunet!csdev!ll1a!spl1!laidbak!att!rutgers!tut.cis.ohio-state.edu!accelerator!baloo.eng.ohio-state.edu!abali
From: abali@baloo.eng.ohio-state.edu (Bulent Abali)
Newsgroups: comp.sys.next
Subject: Re: NeXT Memory - No Error Checking or
Message-ID: <8548@spl1.UUCP>
Date: 2 Nov 88 17:54:23 GMT
References: <549@gt-eedsp.UUCP> <207400001@inmet>
Sender: news@spl1.UUCP
Reply-To: abali@baloo.eng.ohio-state.edu (Bulent Abali)
Organization: Ohio State Univ, College of Engineering
Lines: 20

In article <207400001@inmet> callen@inmet writes:
>Getting back to parity, I'm surprised, too, that NeXT didn't use either
>parity or ECC. There are a number of single-chip ECC solutions available,
>so I can't believe that the cost would have gone up THAT much. But then,

It is not the cost alone which effects the decision of 
using ECC or not. Parity and ECC techniques are real performance 
killers. Generating the check bits for writes, generating and 
comparing the check bits for reads take time. This may cost 
1 to 3 wait states for memory access. Furthermore, byte write and 
halfword write (word=32 bits) operations have an additional 
performance penalty. For such cases, the hardware must first read
the fullword which contains the halfword or byte to be written into,
generate the check bits, and finally write into the memory. So these
type of operations may take twice as long. 

If NeXT didn't put ECC in it's memory, I'll say it is a tradeoff
to get performance, not because of cost. If I were a microprocessor
designer, I would generate the check bits or parity on the chip, 
rather than trying to squeeze in a larger cache.