Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!uunet!bu.edu!buitc!gjc
From: gjc@buitc.bu.edu (George J. Carrette)
Newsgroups: comp.arch
Subject: machines with some loadable microcode are easier to fix
Keywords: microcode hardware bugs
Message-ID: <71537@bu.edu.bu.edu>
Date: 3 Jan 91 18:14:41 GMT
Sender: news@bu.edu.bu.edu
Reply-To: gjc@buitc.bu.edu (George J. Carrette)
Organization: Information Technology, Boston University, Boston, MA, USA
Lines: 31

The subject line is a good summary, one reason that hardware designers
and vendors prefered machines with loadable microstore (and by the same
token machines that have microcode) was that it made it possible to fix
some "hardware" bugs without replacing chips or boards.

RISC implementations have no microcode, so fixing a hardware bug
means replacing a chip. 

A few months ago I posted to a couple news groups (not this one) a
program that crashed all RISC machines that it had been tried on,
but not the VAX and 68020 machines that I had tried it on. 

Much flaming resulted as expected, since I made the unfair statement
that the system vendors of RISC machines did significantly less
quality of testing than the vendors of CISC machines.

There was also the unsupported statement that RISC machines, with
their rich set of "result is undefined" sequences of instructions were
more difficult to give a high quality of testing and/or engineering
proof of correctness.

Be that as it may, since that time there have been reported
actual HARDWARE bugs in certain SPARC implementations.

Perhaps these have been already discussed in this news group?
(I've just started reading it).

-gjc

p.s. In a the next article I am posting an updated version of CRASHME.C
which people can use to investigate these issues further.