23 Sep
2001
23 Sep
'01
6:53 a.m.
Chris Kennedy wrote:
Really? An assembly level program, running on an already microcoded processor
is still microcode? Do you put this sort of experiance on your resume?
Um, emulators can be written in microcode. Perhaps this is how the K6 works?
<snip>
Bob Shannon wrote:
[stuff deleted]
Not at all.
I'm not even attempting to define 'microcode' specifically.
The application in question was an emaulation of a PDP-11 running on a Pentium
processor, in Pentium assembly level code. This is unquestionably emulation,
and is a full layer of abstraction away from the Pentium's physical microcode.
To describe this application as 'microcode' is indefensibly wrong.
<snip>
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. 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.
Not a bad definition. Now apply this to the concept of emulating a PDP-11 on
a Pentium please.
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 disagree with your interpretation of IBM's definition. Firmware is clearly
program-addressable!
<snip>
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.
First off, I strongly doubt that the majority of list members have ever written
true microcode. Its just not commonly done.
Secondly the use of a non-microprogrammed machine has nothing to do with
the definition of emulation, nor microcode.
Lastly, I'm not familiar with the K6 microarchitecture, so I cannot comment on
its operation.
But lets remind ourselves of the actual issue here. Running an assembly-level
program on a Pentium which emulates the instruction set of a PDP-11.
This was described as microcode. Its clearly an assembly-language emulation.
Once again, whats unclear here?
<snip>
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. 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.
But firmware IS program-addressable, now isn't it? I don't agree that my
concept of 'microcode' is at odds with IBM's.