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

From: Bob Shannon <bshannon_at_tiac.net>
Date: Sun Sep 23 14:31:21 2001

Tony Duell wrote:

<snip>

> > I understand your confusion here, but in this case there already is something
>
> I'm not confused. I know what the terms conventionally mean. I would not
> normally descibe a program running on a microprocessor as 'microcode'
> (for all some books do make that mistake, and DEC even once called
> anything running microcode a 'microprocessor' (like the microcoded comms
> processors they used on things like the DMC and DMR cards) for all they
> were not single-chip processors (which, IMHO is the conventional
> definition of microprocessor).
>
> I, however, don't see it as necessarily wrong to look at a system at a
> different level...

Ok, so normally code running on a microprocessor is 'not normally' described as
microcode. Lets start from here....

<snip>

> OK, now replace that Pentium chip with an ARM (which contains no internal
> microcode). Is the emulation firmware in ROM now ARM machine code, or
> microcode, or both (I would claim it could be considered to be both).

Ok, so now we have code running on an ARM microprocessor, a non-microcoded
architecture.

So now why would it be correct to call the program running on a non-microcoded
microprocessor, "microcode"? Clearly on a non-microprogrammed machine, there is no
microcode. So does choosing a different name suddenly turn the ARM inso a microcoded
architecture?

Very clearly it does not. So simply choosing to use terms to describe totaly different
levels of hardware abstraction is not such a good idea.

> Let's suppose I make a PDP11-compatible CPU by using a Pentium (or an
> ARM), that firmware emulation machine/micro code and the memory interface
> as I've described. To the _user_, that's a processor that runs PDP11
> machine code programs. I could boot RT11 or RSX on it. Inside there's a
> program that controls the operation of that PDP11-compatible processor. I
> think it's justified to call that microcode under some circumstances, and
> Pentium/ARM machine code under others.

This is called emulation, not microcode. Otherwise your application gets to define a
processor as microcoded or not.

I think the problem here is that your describing an assembly level program which performs a
similar function to the actual microcode in say, a PDP 11/45. But performing the same
function on a different machine already has a term, its emulation.

Emulation is simply not microcode, and its not correct to describe it as such. Try bending
terminology like this on your resume some time, and see how the industry reacts.

> > The code in the ROM is still made of instructions which are interpreted by existing
> > microcode. The difference is very very clear at the hardware level.
>
> Not to me it's not. In fact I'm looking for an unabiguous distinction
> between microcode and a finite state machine. I know what both of them
> are (having designed both on many occasions) and as far as I can see
> there is little electronic differece between them.

Back up for a moment, and look at the application your suggesting here. An assembly level
program, running on a microcoded machine, emulatating another processor.

So now you replace the microcoded processor with a non-microcoded one, and still claim
there is microcode present?

> Suppose you have a circuit. It consists of an N-bit latch, outputs to
> some combinatorial logic circuit (which we can, of course, make from a
> ROM). The combinatorial circuit has other inputs from the rest of the
> system. Outputs of the combinatorial circuit go to to other parts of the
> system (to control it) and also back to the inputs of the N-bit latch.
>
> Now, that, of course, is a classic finite state machine. But hang on a
> second. Suppose the 'other' inputs to the combinatorial circuit come from
> the machine code instruction latch in a processor. The outputs control
> the ALU, data path muxes, and so on. Then it certainly looks like
> microcode to me.

Not at all!

Processors that use this design method are quite common. Usually there are state and cycle
counters. Combinatorial logic is used to decode the instruction register, state and cycle
counters to drive the control signals for the CPU logic.

This is NOT microcode. This is a non-microprogrammed machine. An example of this is the
good old 8080. Contrast this to the design of the Pentium or other microprogrammed design.
The presence of a control store eliminates all that combinatorial logic.

I reccomend you get a copy of Mick and Brick, Bit Slice Microprocessor Design.
An excellent book, it even has plans for a PDP-11 emulation with 2901's.

<snip>

> Let me start with a somewhat silly example.
>
> I need to make a circuit that outputs an incrementing 8 bit binary
> number. I decide to do it in a somewhat odd way (for no good reason other
> than I'm eccentric).
>
> I decide to use a Z80 processor. And to write a little program to output
> an incrementing count to an output port. I map an 8 bit latch at that
> output port address, and use that as my 8 bit output.

<snip>

>
> (Apologies for any bugs in that, but you should get the idea).
>
> OK, so far so good. It is clear that the contents of that ROM are
> firmware/software (in this case Z80 machine code).
>
> But as a hardware designer, I can regard that ROM as a programmable
> combinatorial circuit (in fact it's really a fixed AND matrix followed by
> a programmable OR matrix). So I can write a logic equation for each
> output bit of the ROM, in terms of the address inputs.

Understood. But look at the complexity of altering the actual combinatorial logic
and the firmware. Clearly the firmware is much more practical to alter, and this
is why microprocessors are so popular.

But this, as you say, it still Z80 machine code. Inside that Z80 there are huge
areas of combinatorial logic that decode the instruction register, cycle and state counters
to drive the control signals for the CPU logic. (the Z80 is not microcoded either)

If you replaced all that combinatorial logic with a ROM, the contents of that ROM (no the
physical ROM itself) would become microcode.

So its not the gates, its the logical expressions they encode, and its a full layer of
complexity below Z80 machine code.

<snip>

> I now take some TTL gate chips and wire up circuits to implement them.
> And replace the ROM with those circuits (as I said, I'm eccentric).
>
> The system still works as it did before. The Z80 sees the same
> instructions....
>
> However, it's not at all clear to me that the gates wired up like that
> should automatically be called 'firmware' even though they replaced a ROM
> contianing firmware. And if they should, is there a clear test to
> determine when a mass of gates is to be called 'firmware'?

See above.

> > like the AM2910 microprogram sequencer.
> >
> > So the presence of state machines (you can't run microcode without them!) is not
> > an issue here.
>
> Actually, I am sure it's possible to make the control system of a
> processor where the only state machine is the combination of the
> microcode address latch and the microcode PROMs. There need not be other
> state machines 'below' the microcode.

Correct. And the contents of the PROMs is the microcode, not the PROMs themselves, as
described above.

<snip>

> OK, getting back to the original PDP11 emulator, why can't we call
> Intel's microcode in the Pentium 'nanocode', the emulator firmware
> 'microcode' and the user's PDP11 program 'machine code'?

Because its basically the same thing that other manufactuers call microcode, and
being its Intel's processor, they get to make these choices.

You can choose to redefine all the terms you like, but that does not make your
usage correct, or more correct than the acutal manufactuers terms.

> > Basically, if a machine is already microcoded, the term is already taken.
>
> Ah, so if somebody has already claimed something to be microcode, then
> that's what it is, and we can't consider it as something else. Odd....

Not odd at all, the manufactuer is using terminology in a standard way so that it is clearly
understood by the industry.

<snip>

> > But I still cannot call this binary program 'microcode' on the 2114 simply because the
> > 2114 is not microprogrammed.
>
> True enough (otherwise, as I said a couple of messages back we'd have the
> absurd situation that the same program would be microcode on a P850 [1]
> and machine code on a P851 [2])

Ok, so then running a PDP-11 emulation on an ARM would be...

A, Emulation.

B, Emulation.

C, Emulation, or

D, Microcode, because I feel like calling it that.

<snip>

> Sure.... But I am now looking for an unambiguous test (note : Not 'this
> is what it's normally called') to distinguish between the microcode in a
> microcoded processor (which interprets user machine code instuctions and
> controls the data path, etc in the processor) and what would normally be
> called 'an emulator' running on a RISC processor (with no internal
> microcode) that interprets the intruction set of another processor (here
> the PDP11) and also 'runs directly on the hardware'.
>
> -tony

Its all about how its implemented.

If the machine level instruction set of a processor is implemented with fixed, combinatorial
logic as opposed to a stored 'microprogram', its not a microprogrammed design.

If you then use the machine code for that machine to emulate another processor, you are
writing an emulator. The machine code may, or may not be microprogrammed, it makes no
difference in this case.

If you alter or create the microprogram of a microcoded processor to emulate another
processor, you are writing microcode, and an emulator at once, your actually writing the
emulator in microcode.

But this is not what was proposed at all. What was proposed was writing an emulator in
machine code, on an already microprogrammed processor, and calling the result 'microcode'.

This appears to be totally unambiguous, unless I missed something.
Received on Sun Sep 23 2001 - 14:31:21 BST