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.