Newsgroups: comp.arch
Path: utzoo!henry
From: henry@zoo.toronto.edu (Henry Spencer)
Subject: Re: machines with some loadable microcode are easier to fix
Message-ID: <1991Jan6.033536.14108@zoo.toronto.edu>
Organization: U of Toronto Zoology
References: <71537@bu.edu.bu.edu>
Date: Sun, 6 Jan 91 03:35:36 GMT

In article <71537@bu.edu.bu.edu> gjc@buitc.bu.edu (George J. Carrette) writes:
>RISC implementations have no microcode, so fixing a hardware bug
>means replacing a chip. 

The same is true of most CISCs actually in the field, unless you weight
the count by size.  Neither of the archetypal CISCs -- the original 360
line and the pdp11 -- used software-loadable microcode, although their
less influential successors did.  In fact, no pdp11 has *ever* used
loadable microcode for its normal instruction set, although one or two
offered it as an option for specialized user extensions.  And modern
VLSI CISCs invariably use ROMs for microcode.

If I were cynical (who, me :-)), I would suggest that RAM microcode was
attractive only when the product

	architectural_complexity * desired_performance * urgency

exceeded some threshold where the manufacturer could be confident of full
debugging and optimization before release.

>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. 

In case you didn't notice, it crashed some other CISCs and failed to crash
a number of RISCs when people tried it out more widely.
-- 
"The average pointer, statistically,    |Henry Spencer at U of Toronto Zoology
points somewhere in X." -Hugh Redelmeier| henry@zoo.toronto.edu   utzoo!henry