Newsgroups: comp.arch
Path: utzoo!henry
From: henry@utzoo.uucp (Henry Spencer)
Subject: Re: Claimed bug in 80286
Message-ID: <1989Aug13.023601.594@utzoo.uucp>
Organization: U of Toronto Zoology
References: <1717@brwa.inmos.co.uk> <15963@vail.ICO.ISC.COM> <1596@crdgw1.crd.ge.com> <7467@ecsvax.UUCP>
Date: Sun, 13 Aug 89 02:36:01 GMT

In article <7467@ecsvax.UUCP> urjlew@ecsvax.UUCP (Rostyk Lewyckyj) writes:
>1. Suppose I have a computer designed/built at the time this version
>of the chip was being sold. Suppose the designers had the bug sheets
>and included the proper hardware fix, so that the software writers
>did not have to be aware of the bug in the chip. Suppose that now
>for whatever reason I replace the old 80286 chip with a new one that
>does not have the bug.  What is the effect of the extra hardware
>from the hardware fix on the operation of the new chip in that
>computer? Does it introduce a new bug?

Quite possibly.  As they say, "your warranty is void".  Sensible designers
will try to come up with a fix that won't interfere with debugged chips,
but not all designers are sensible and such fixes sometimes aren't possible.

>2. Suppose that I have an old computer without the hardware fix,
>an old chip, but the software writers of my system programmed
>around the bug. What happens when I replace the chip? (Or How
>likely is it that now the software won't work right??)

Again, "your warranty is void".  Sensible software people will usually try
to avoid the trouble area completely, rather than finding a trick that will
make the buggy chip do the right thing, but this isn't always possible and
the software people sometimes aren't sensible.  ("You want us to meet your
deadline *and* do things right?  That's going to cost you extra...")

>3. How paranoid does a software developer need to be in writing
>his programs? Is it necessary to get the bug lists for all previous
>versions of the processor being programmed and write code that
>avoids the union of all the bugs? ...

Well, on sensible machines this is mostly the compiler writer's worry.
On a 286, of course, it bites everyone.  Getting old bug lists could
be very difficult, and working around them can be seriously hard.
Most software writers probably just take the easy way out, doing
workarounds for any that are known to be widespread and ignoring
the rest on the grounds that making the hardware work right is someone
else's problem.  (Some of us feel that the presence of a 286 CPU in a
machine is a bug, one which should be given the latter treatment... :-))
-- 
V7 /bin/mail source: 554 lines.|     Henry Spencer at U of Toronto Zoology
1989 X.400 specs: 2200+ pages. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu