Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!sdd.hp.com!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!cbnewsj!davet
From: davet@cbnewsj.att.com (Dave Tutelman)
Newsgroups: comp.sys.ibm.pc.hardware
Subject: Re: Memory Parity. Is It Really Needed
Summary: Yup!
Message-ID: <1991Apr9.120520.15725@cbnewsj.att.com>
Date: 9 Apr 91 12:05:20 GMT
References: <1865@svin02.info.win.tue.nl> <2258@pdxgate.UUCP> <1991Apr8.183732.1@dev8o.mdcbbs.com>
Distribution: na
Organization: AT&T Bell Labs - Lincroft, NJ
Lines: 41

In article <1991Apr8.183732.1@dev8o.mdcbbs.com> campbell@dev8o.mdcbbs.com (Tim Campbell) writes:
>
>You _CAN_ control what happens when the error occurs.  The occurance of the
>error generates an interrupt.  Anyone can attach that interrupt vector...
	Tim is absolutely right.  I've done that myself, specifically for
	a memory test program.  (You have to, if your memory tester is to
	function long enough to tell you about the errors it discovers.
	Think about it.)
	But...

>...If you want you can plug in a far pointer to an 
>IRET instruction in which case the machine will do absolutely nothing 
>(although _I_ personally wouldn't advise this approach) and proceed merily
>along with corrupt data.
	Again, I agree with Tim (both that you can and that you shouldn't).

	There's an assumption here that the DATA is bad.  But a stored-program
	computer is as likely to have the bit error in the PROGRAM.  Three
	things could happen:
	   1.	The program could hang, because of the bad instruction.
		(For practical purposes, indistinguishable from just
		locking up due to BIOS default parity error handling,
		except that you don't get the message on-screen.)
	   2.	The program could do something wrong, visibly (trashing
		the screen) or invisibly (trashing your data).  The latter
		is the most pathological possible consequence, much worse
		than simply saving a byte with a bad bit (what happens
		if the data has the parity error, and is ignored).
	   3.	You could luck out, and no serious consequence accrues.

	I don't think I'd trust anything I cared about, on the chance that
	I'll get consequence #3.

Dave
+---------------------------------------------------------------+
|    Dave Tutelman						|
|    Physical - AT&T Bell Labs  -  Lincroft, NJ	  07738		|
|    Logical -  dmt@pegasus.att.com				|
|    Audible -  (908) 576 2194  (Office)			|
|		(908) 922 9576  (Home)				|
+---------------------------------------------------------------+