Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!sco!gorn!filbo
From: filbo@gorn.santa-cruz.ca.us (Bela Lubkin)
Newsgroups: comp.arch
Subject: Re: IBM PC prehistory
Message-ID: <121.filbo@gorn.santa-cruz.ca.us>
Date: 29 Dec 89 08:13:42 GMT
References: <1957@crdos1.crd.ge.COM> <73@zds-ux.UUCP>
Lines: 59
X-Claimer: I >am< R Pentomino!

In article <1957@crdos1.crd.ge.COM> Wm E Davidsen Jr writes:
>  I'm most surprized at the parity. They was IBM's big contribution to
>PC technology. Up to then all the PCs were just 8 bits, and most of us
>who wanted reliability ran static RAM instead of dynamic. I still have
>an S100 system with about 1.5MB of CMOS static in 4Kx8 packages as I
>recall. Same pinout as a 32k ROM, allowing installation of firmware as
>desired.

I speak in the past tense here because I don't know if the current
implementation has improved any, and I haven't gotten a parity error on
a PClone in over three years:

I'm not convinced that parity RAM benefitted reliability in early IBM
PCs.  The software implementation was so poor that the parity hardware
actually degraded reliability.  A parity error caused an instant,
irrecoverable crash.  After a parity error you had to power down the
machine and could not even save a memory image for later
analysis/extraction of important data.  As I see it, the presence of
parity memory effectively made the system 9/8 as likely to suffer a bad
bit, since there was 9/8 as much memory to go bad!

Software support for parity (and for uncorrectable ECC errors) should be
much more flexible.  At the least, it should offer options like: reboot;
run memory test on affected area; save memory image; "correct" parity
bit and continue; continue with parity checking disabled.  These would
allow at least some chance to recover important work-in-progress.

Of course, under a "real" operating system, the OS would know which
task's memory was affected; would hold that task while signaling other
tasks to do an orderly shutdown; would then restart that task and allow
it to attempt to shut down while keeping a journal of changes it makes
to files, in case it had gone insane.  In some cases the OS could
relocate the affected memory block (particularly in virtual memory
systems) and run memory tests on the bad area.  If it found a stuck bit,
it would know which bit to correct in the affected task and would be
able to restart it without any loss.

How is parity handled in larger systems?  I know about ECC; are there
any larger systems that use just parity, but attempt to handle it more
reasonably?  How do larger systems handle ECC correction failures?

In article <73@zds-ux.UUCP> Gerry Gleason writes:
>I don't know why, but there was a significant price differential between
>8088's and 8086's.

This was probably a marketing decision: perceived value of a "16-bit"
chip is higher than an 8-bit chip -- even if the distinction is ONLY at
the bus level.

Witness the 80386 and 80386-SX.  You can't tell me that the day it
started shipping, Intel could produce a 386SX more cheaply than a 386.
98% of the silicon is (logically) identical; long-term production yields
should be comparable; but the 386SX hadn't had time to mature.  Yet
initial list prices for the 386SX were considerably lower than the
comparable 386-16.  Intel sets prices by perceived value, not costs.

Bela Lubkin    * *    //  filbo@gorn.santa-cruz.ca.us  CI$: 73047,1112 (slow)
     @       * *     //  belal@sco.com  ..ucbvax!ucscc!{gorn!filbo,sco!belal}
R Pentomino    *   \X/  Filbo @ Pyrzqxgl +408-476-4633 and XBBS +408-476-4945