I think you may be mistaken there, Tony. If you wire up a set of gates to
generate the outputs otherwise generated by a PROM, it's hardware, not
firmware, since it's hard-wired and not programmable.
Likewise, if you configure a CPLD to contain what (a logic function) would
otherwise have been generated with discrete LSI/MSI/SSI logic, it's still
firmware. From what I have gathered over the years. If it can't be removed
from the device without making the function of the item go away, then it's
hardware or firmware. If it's possible to remove it and leave the
device/system of which it's a component intact, having simply removed that one
function it's probably firmware. If it is copied from one medium to another
before it becomes part of the system, it's probably software, particularly if
it resides in a locus capable of being routinely modified, it's probably
software. (notice the need for "wiggle-room")/
I don't know where this leaves things like CDROMs, FLASH memory, FPGA's (which
are configurable in their internal RAM from an external ROM or whatever) since
they seem to blur those boundaries.
However, you'll play hell trying to modify the contents of Wozniak's
state-machine PROMs, so that's probably firmware or hardware, though it relies
heavily on what's probably software to help it work properly, while you'll
have trouble convincing anyone that the stuff on a floppy diskette is anything
other than software, even though it might be the microcode that makes your
'370 run.
Dick
----- Original Message -----
From: "Tony Duell" <ard_at_p850ug1.demon.co.uk>
To: <classiccmp_at_classiccmp.org>
Sent: Tuesday, April 09, 2002 6:21 PM
Subject: Re: TTL computing
> >
> > Tony, you're wandering into the semantic quagmire of distinction between
> > hardware and firmware and software.
>
> Yes, I know... The point is that many of these terms ('hardware',
> 'software', 'firmware', 'microcode', 'state machine', etc) don't have
> absolutely rigorous definitions. OK, we all know what, say 'firmware' is,
> but then if I wire up a pile of gates to replace a ROM containing a
> program (which is what we'd call 'firmware'), is the result 'firmware',
> 'hardware', both, or neither :-)
>
> >
> > 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,
>
> This sounds like a good definition until you realise that concepts like
> 'procrssor' and 'instruction set' are not precisely defined either. I
> could argue that a terminal, taking in characters over a serial line, and
> changing its internal state (positioning cursor, clearing to the end of
> line, etc) was in fact a processor with the characters as the instrucion
> set. At which point the terminal firmware becomes microcode.
>
> The problem is not helped by the fact that some manufacturers use these
> terms (IMHO) incorrectly....
>
> We've had this discussion before. It gets nowhere, and seems pointless
> provided if there's no real confusion.
>
> > 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.
>
> Perhaps you can give me a defintion of state machine which excludes a
> (microcoded) processor. I will accept that not all state machines are
> microcoded processors, but I'll have difficulty accepting any form of
> processor that's not a stete machine.
>
> -tony
>
>
Received on Tue Apr 09 2002 - 20:55:36 BST