Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!samsung!olivea!orc!inews!iwarp.intel.com!csun!kithrup!sef
From: sef@kithrup.COM (Sean Eric Fagan)
Newsgroups: comp.arch
Subject: Re: machines with some loadable microcode are easier to fix
Keywords: microcode hardware bugs
Message-ID: <1991Jan04.035359.12547@kithrup.COM>
Date: 4 Jan 91 03:53:59 GMT
References: <71537@bu.edu.bu.edu>
Organization: Kithrup Enterprises, Ltd.
Lines: 26

In article <71537@bu.edu.bu.edu> gjc@buitc.bu.edu (George J. Carrette) writes:
>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. 

John Mashey once posted that simulating a MIPS R3000 (I think it was),
completely in software, from power up to single user mode, took something
like seven days.  (John, sorry if I've gotten something wrong.)

How long do you think it would take to do the same thing for, say, VAXen,
Cybers (180 state, that is), or any other machine with loadable ucode?

Which do you think is going to result in more sales:  selling and shipping a
machine for which you need to send out periodic uCode upgrades, or building 
a bug-free implementation by shipping time, which is three or more time 
faster than the one with ucode?  Assuming neither party is IBM or DEC, that
is 8-).

-- 
Sean Eric Fagan  | "I made the universe, but please don't blame me for it;
sef@kithrup.COM  |  I had a bellyache at the time."
-----------------+           -- The Turtle (Stephen King, _It_)
Any opinions expressed are my own, and generally unpopular with others.