23 Sep
2001
23 Sep
'01
7:31 a.m.
Tony Duell wrote:
<snip>
Ok, so normally code running on a microprocessor is 'not normally' described as
microcode. Lets start from here....
<snip>
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?
Correct. And the contents of the PROMs is the microcode, not the PROMs themselves, as
described above.
<snip>
Not odd at all, the manufactuer is using terminology in a standard way so that it is
clearly
understood by the industry.
<snip>
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>
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, 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. 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. 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.... 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]) 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.