microcoding a PC into a PDP-11 (was: RE: Classic Computers vs.

From: Bob Shannon <bshannon_at_tiac.net>
Date: Sun Sep 23 13:53:04 2001

Chris Kennedy wrote:

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

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>

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

Really? An assembly level program, running on an already microcoded processor
is still microcode? Do you put this sort of experiance on your resume?



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

Um, emulators can be written in microcode. Perhaps this is how the K6 works?

<snip>

> 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.
Received on Sun Sep 23 2001 - 13:53:04 BST