Bob Shannon wrote:
[stuff deleted]
> Because there already is microcode running, or your Pentium cannot run
your assembly
> level program. Whats unclear here?
I'm reading this as suggesting that if any of the logic used to deliver a
set
of abstractions is soft then the next higher level of abstraction (which is
_usually_ the ISA of the processor) cannot be considered microcode. That
might be a useful metric, but, as you acknowledge, nanocode exists, so the
utility
of this metric as a definition of microcode vs. something else is at least
suspect.
> If you want to run microcode, fire up a PERQ. If you write assembly-level
programs for
> a Pentium, your writing an assembly level program, not CPU microcode.
>
> Once again, these terms have definitions already. Learn them, and use
them correctly,
> please.
Well, here's _one_ textbook definition of microcode:
"...programming that is ordinarily not program-addressable, but, unlike
hardwired
logic, is capable of being modified..."
which says nothing about other levels of microcode, nor about the complexity
of the abstraction on which the microprogram executes.
It's notable that IBM uses the "well-defined" term "microcode" to describe
what
most of us would consider "firmware". The definition of microcode can
certainly
be fuzzy, and Tony has already postulated an implementation using processors
rather than discrete logic or bitslices that would meet the definition
above.
> I have no idea Tony. But I've written microcode, and also assembly level
code. There
> is a vast difference between them.
I'm fairly certain most of us have written both, and this thread is
prompting some of
us to ask just _what_ the real difference is between the two. Thus far I've
seen
two arguments advanced as to why what is being described is an "emulator"
rather
than "microcode", and they seem to revolve around two arguments:
- It can't be called microcode if there's microcode beneath the abstraction
at
which you're coding. Obviously this one can be dismissed by using a
non-microcoded
processor as the functional unit.
- There is some level of hardware abstraction above which it can't be
considered
microcode. I'm not sure how this gets translated into a quantitative
metric.
It's can't run on anything more complex than a sequencer? By that
definition
the code on the K6 isn't microcode, it's an emulator. Execution of an
"instruction" takes more than one memory cycle? Given speculative
fetching
of blocks of memory on contemporary processors it's possible for an
"instruction" to execute with zero memory references. It's just "too
complex"? By that definition the B1700/1800 didn't have an assembly
language.
What other characteristics might be used as metrics? Long instructions
words?
There are certainly VLIW machines out there, so that doesn't work. The need
to "carefully" schedule instructions? That demands certainly exists in
some implementations of some RISC ISAs.
I'm having trouble seeing hard-and-fast rules here.
> All I can say is that your useage of the terms is totally incorrect as
they are used by
> people who write both assembly-level and microprograms.
Well, I've done both, and at this point I can hardly agree that Tony's usage
is
"totally incorrect".
> There is a full order of magnitude of difference in the degree of hardware
> abstraction between these two very different forms of programming.
Which takes me back to the K6. A die with dual RISC processors running code
which fetches, cracks and "executes" X86 instructions. By the definition
being
advanced by Tony this is clearly microcode; by your definition it's not --
it's
an emulator -- yet any CPU designer that I know (including myself) would
certainly consider it to be microcode.
In a purely empirical sense, the appellation "microcode" isn't bounded by
the complexity of the underlying hardware abstraction. It's nothing more
than part of the logic used to deliver another abstraction. Likewise
there's
nothing to prevent an "emulator" from running out of control store -- the
most absurd of which being machines which performed simultaneous emulations
of several ISAs, performing microcontext switching between them.
> It appears to me that your trying to defend the incorrect usage of a
cool-sounding term,
> you clearly have some emotional attachment to.
Who has an emotional attachment? I've been writing both microprograms and
assemhly
crap for more than a quarter century and _I_ can't see a clear distinction,
and
your definition is clearly at odds with that used by IBM -- which at the
very least
suggests that the term is not as well-defined as you'd like to believe.
> As this list is about computers and their technology, I wanted to step
forward and
> correct this misuse of terms to prevent others from learning a highly
incorrect usage
> that can only sow more confusion.
Thank god you're here!
--
Chris Kennedy
chris_at_mainecoon.com
http://www.mainecoon.com
PGP fingerprint: 4E99 10B6 7253 B048 6685 6CBC 55E1 20A3 108D AB97
Received on Sat Sep 22 2001 - 10:55:01 BST