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

From: Bob Shannon <bshannon_at_tiac.net>
Date: Sat Sep 22 09:32:33 2001

Tony Duell wrote:

<snip>

> > While the line between assembly code and microcode is often grey, when it
>
> Ah, you've finally admitted that the distinction is somewhat unclear in
> some cases. This doesn't make the terms 'machine code' and 'microcode'
> useless of course, but it may also mean (and does IMHO) that the PDP11
> emulator that started this thread can be considered to be microcode.

Yes, the distinction is unclear in some cases, but not at the levels your trying to
fit these terms into.

> > takes more than an instruction to read main memory, chances are your at the
>
> 'Instruction' or 'Microcycle'? Technically it takes one microinstruction
> to get a PERQ to access memory, but several microcycles. You have to set
> up the address, execute the memory read microinstruction (which sets a
> state machine running to do the memory access) and then read in the data
> on subsequent microcycles.

Micro-instruction technically speaking. The PERQ takes several microinstructions to
read main memory, while an assembly level instruction may perform several memory cycles
per instruction.

There is an huge, and very clear difference here.

<snip>

> Suppose I write a PDP11 Emulator program for the Pentium. But this one is
> a little strange in that it uses hardly any RAM on the Pentium bus (maybe
> a couple of K for a stack and state varialbles, and so on). It expects to
> find a few I/O ports in the Pentium I/O space that are linked to normal
> RAM (say 22 bits output for the address, 16 bits out/16 bits in for the
> data, and a few control lines). It accesses the user program in that
> memory by executing several I/O instructions on the Pentium (and other
> instructions besides). It outputs the address, fiddles with the mrmory
> control lines, reads in the data word.

The point here is, your running assembly-level instructions that are implemented with
true microcode already. So you clearly are not writing microcode, your writing assembly
level code for a Pentium. This is totally clear in your first sentance above!

> I now take a bare Pentium CPU, stick it on a PCB (with the clock circuit,
> etc), add this 'emulator' in a ROM on the Pentium bus, and then add the
> I/O ports accessing memory.
>
> Is that emulator now microcode by your definiton? If not, why not?

No, its not microcode. Its an assembly-level program that emulates a PDP11.

Why not?

Because there already is microcode running, or your Pentium cannot run your assembly
level program. Whats unclear here?

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.

<snip>

> > I suppose this completely depends on which books you have read.
>
> Eh???? Which books do you think I've read, then?

I have no idea Tony. But I've written microcode, and also assembly level code. There
is a vast difference between them.

<snip>

> Not to me it isn't, and I don't have any problem with understanding
> hardware at the gate level (or below).
>
> -tony

Sorry, I don't seem to be able to help 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. There is a full order of
magnitude of difference in the degree of hardware abstraction between these two very
different forms of programming.

It appears to me that your trying to defend the incorrect usage of a cool-sounding term,
you clearly have some emotional attachment to.

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.
Received on Sat Sep 22 2001 - 09:32:33 BST