🚀 go-pugleaf

In article <83@reality1.uucp> james@reality1.UUCP (james) writes:
>IN article <405@intsc.UUCP>, tomk@intsc.UUCP (Tom Kohrs) wrote:
>> How much gets found and fixed before the parts ship in volume has
>> more to do with marketing considerations than the technical correctness of
>> the chip.  Long term testing is done by trying to put the chip through every
>> conceivable sequence of events (both hardware and software) and by following
>> up on problem reports from the field. You would be amazed at what some people 
>> will try to do to a chip.
>
>Well, gee, I can't think of any bugs in the MC68020 (not XC68020) offhand,
>although the argument might be that they haven't been found yet, or that
>Motorola has had better luck hiding them than Intel has had. [...]

Would it have made any difference if Intel had called the I80286 the
XI80286 before a certain release of the chip?  All of the so-called
X parts I have are labelled "MC68020".  The argument you're putting forth
is syntactic; the semantics are identical.

What really irritates me is releasing different revisions of these
parts with no way for the S/W to be able to detect the different
revisions.  It's terrible that Motorola went to the trouble of dumping
a revision number of the MC68020 in the microstate during certain
exceptions but has never updated that revision number.  This means
that the bug fixes for the X parts must be retained in current releases
of software because there is no way in S/W to tell that which machines
in the field have XC68020's in them.

Around here we have a joke that the first update of the revision
number for the MC68020 will be in the MC68030.

I'm not as familiar with the Intel parts so I don't know if they have
the same problems -- I would assume so.  In any case, why
don't you microprocessor developers out there take pity on the
rest of us and update your revision numbers once in a while.
-- 

Mark Campbell    Phone: (803)-791-6697     E-Mail: !ncsu!ncrcae!sauron!campbell