Tony, you're wandering into the semantic quagmire of distinction between
hardware and firmware and software.
The difference between microcode and other firmware, used, for example, to
define a state machine, is that the "microcode" is executed by a processor of
some sort that is an entity unto itself. Microcode is used in two-layered
designs, wherein the microengine executes the microcode which, in effect,
fully defines the system of which it is a component. In some cases, changing
the microcode will completely redefine the instruction set, register set,
cache configuration, etc. In some cases, it can even redefine the word width.
That's certainly seldom the case with state machines.
RISC machines were an outgrowth of work on developing code for microengines in
their native mode in hopes of capitalizing on their (then) high speed relative
to conventional processors.
Dick
----- Original Message -----
From: "Tony Duell" <ard_at_p850ug1.demon.co.uk>
To: <classiccmp_at_classiccmp.org>
Sent: Tuesday, April 09, 2002 4:12 PM
Subject: Re: TTL computing
> >
> > This might be a good time to point out that the presence of PROMs doesn't
> > automatically imply the presence of "microcode" since PROMs were often
used
>
> Ture. Similarly you can (IMHO) have microcode without PROMs (or other
> memory devices)[1]. In fact I am still looking for an unambiguous
> distinction between microcode and a state machine. Since the circuitry is
> so similar, I suspect whether something is microcoded is more to do with
> the design philiosophy than the circuity ;-).
>
> [1] A PROM is basically a 1-of-n decoder with some of the outputs ORed
> together (selecting which outputs are ORed for each output bit is more
> commonly called 'programming the PROM' :-)). So in theory you could take
> a tree of '138s and OR the appropriate outputs together to make a
> pseudoPROM. If you put that in place of the microcode PROMs in a
> processor the circuitry would be electrically identical [2]. And I can't
> see a good reason to claim that the result is no longer microcoded.
>
> [2] OK, the propagation delay would mean it would no longer run at
> anything like the same clock rate, but....
>
> > for instruction decoding and other simple logic functions. Microcode
implies
> > the presence of a low-level processor, and I saw little of that up to the
> > point at which bit-slice, e.g. AM2900-series or Intel 3000-series, became
>
> Then I have to conclude you didn't look at many of the early 1970's
> minicomputers..... Many (but by no means all, agreed) of those machines
> used TTL-based processors which were certainly microcoded by any
> reasonable definition of 'microcode'.
>
> In particular every PDP11 with the exception of the 11/20 (and therefore
> also the 11/15) is microcoded. And no PDP11 I've ever seen uses 2900 or
> 3000 bit-slice chips for the main CPU.
>
> The Philips P850 is not microcoded. All other P800 series machines I've
> seen are, but those used either custom Philips bitslice parts (SPALU --
> Scratch Pad Arithmetic Logic Unit) or AM2900 series. I believe the P855
> was a microcoded TTL design, but I don't have the schematics to check
>
> > popular, though PROMs did appear from time to time in functions other than
> > simple microcode.
>
> Not as commonly as you might think. At the time PROMs were expensive and
> not many people had programmers [2]. Use for 'random logic' replacement
> was not common. For example the PDP11/45 (which uses PROMs for the
> microcode store) has one board which is almost entirely gates (including
> a lot of AOIs) for microocde branch control.
>
>
> [2] It is claimed this is one reason that one of the first boot ROMs for the
> PDP11 series was a diode metrix not a fusible link PROM. Everybody has a
> soldering iron and cutters so can reprogram the diode matrix :-) [And
> as a result I have a scheamtic of the bootstrap loader for one of my
> PDP11s...]
>
> -tony
>
>
Received on Tue Apr 09 2002 - 18:27:21 BST