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

From: Bob Shannon <bshannon_at_tiac.net>
Date: Sat Sep 22 09:13:25 2001

Hi Tony,

Tony Duell wrote:

> > > I'm adding one more level of abstraction -- microcoding on the microcoded
> > > machine, so to speak. Like the Mini PLC-2.
> >
> > An assembly-level program running on a Pentium, technically speaking, is not
> > microcode.
>
> Why can't the Pentium be a a microcode engine, at least in principle (If
> you are going to argue that at the microcode level, accessing main memory
> takes more than 1 instruction, then simply have the Pentium CPU and the
> microcode (or emulator if that's what you want to call it) ROM on its bus,
> and link up someuser RAM memory via I/O ports. Why is the code in the
> ROM in that case not microcode?

I understand your confusion here, but in this case there already is something
defined as microcode. Simply adding another layer of complexity does not change
the underlaying microcode that runs directly on the hardware, its still the microcode
of the engine. This underlaying microcode still implements the instruction set of
the physical CPU hardware.

In the (odd) case you describe above, your still running an assembly-level program on
an already microcoded machine. Such a strange application does not redefine
the existing microcode into 'nanocode'.

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.

> > > > But an writing such an emulator is not 'microprogramming'.
> > >
> > > It is so. I don't know of any rule that says that the micromachine has to
> > > have a particular type of architecture, or that it can't be an off-the-shelf
> > > machine, rather than a collection of AMD 29xx parts.
> >
> > By definition, a microprogram runs directly at the hardware level. A Pentium is
>
> Does it? Define 'hardware level'. There is little conceptual difference
> between microcode and a finite state machine. Are you going to claim that
> if the CPU hardware contains finite state machines (which just about all
> do) then the program in the control store can't be called 'microcode'
> Because if so, I don't know of a single microcoded processor.

The 'hardware level' means that the micro-operations are executed by physical
gates and devices. These gates and devices will (must actually) form state machines,
like the AM2910 microprogram sequencer.

So the presence of state machines (you can't run microcode without them!) is not
an issue here.

> > a microprogramed processor, so an assembly level program running on a
> > microprogrammed machine cannot really be called a microprogram.
>
> Firstly, I've never met a processor that runs _assembly_ language. You
> have to assemble it into machine code first :-).

Hence the term 'assembly level program'.

It this discussion about computers, or terminology?

> Secondly, I still have this problem with the idea that if there's
> already some microcode (or presumably a state machine) in the system then
> the next level of code can't be called microcode.

Some machines do have a programmable layer below the microcode, but its
very rare. Some machines (Interdata?) have nanocode. This is used for very
basic functions like controling main memory addressing modes, etc. Other machines
(like the VAX series, and later Pentiums) have more than one microcoded engine in the
CPU, one for data processing, and another for program flow control.

Basically, if a machine is already microcoded, the term is already taken.

Here's an example of why its completely wrong to use the term microcode for an
assembly language program...

I have a HP 2114A computer. Its not microcoded, it uses state and phase counters, and
a huge array of gates to decode the state, phase, and instruction register contents
into the control strobes that actually run the hardware.

I can run small programs on the 2114, and then take that exact same binary-level code
and enter it into a HP2113E, a true microcoded machine. Now this same binary, machine
language program will run identically (well, much faster, but logically the same).

But I still cannot call this binary program 'microcode' on the 2114 simply because the
2114 is not microprogrammed.

Does this same binary code suddenly become 'microcode' when it runs on the 2114, but
transform into an assembly language program when run on a 2113?

Of course not. The only microcode here is sitting in chips on the 2113 CPU.

(note, the early 2100 series machines describe 'microprogramming' as holding more than
one op-code in an assembly-level instruction, but this is NOT the accepted usage of
the term today)

> Turning it round, would you say that the 'machine code' for an ARM chip
> (which AFAIK contains no traditional microcode) is, in fact really
> microcode? Because it runs directly on the hardware (This definition has
> the absurd cosequence that a program running on a P850 would be
> microcode, but the same program running on a P851 would be machine code).

No, instructions may run directly on the hardware, using the conventional state and
phase counter approach to designing a NON-MICROPROGRAMED processor, like the HP2114,
or your ARM chip.

> > > You can argue that hardware is software, or that software is hardware. It's
> > > all logic. The distinction is pretty academic.
> >
> > Exactly these are terms with fairly well defined meanings!
>
> OK, is the VHDL description of a circuit hardware or software? If I
> program it into an FPGA, is it hardware or software then? If I build it
> from TTL chips, then presumably it's hardware.

VHDL is clearly software. The FPGA itself is hardware. The configuration data
generated by the VHDL is also software that is processed by the FPGA hardware.

This is really back and white. Where is the silicon? Thats the hardware!

> I once convinced a DEC droid that the RK05 bootstrap program in my
> PDP11/45 was _hardware_ and therefore didn't need a license (he was
> trying to claim i needed a license for a M792 board!). I pointed out I
> had a schematic showing which diodes had to be inserted to make that 32
> word diode-matrix ROM contain the RK05 boot program.
>
> No, the terms 'hardware' and 'software' are not totally unabiguous in all
> cases!
>
> -tony

I totally disagree.

Your M792 board is hardware, but the data stored on that board is software.
But that software simply does not have a license agreement.

A EPROM is hardware, but the data held in it is software, and may very well
need a license. A license is not what makes something software Tony, its simply the
fact that its built out of bits rather than silicon.

The line between them is very clear.
Received on Sat Sep 22 2001 - 09:13:25 BST