Our email system was having virus problems last week, so I got the recent
traffic on this thread all at once this morning. It's been very interesting,
even when I could not follow all the logic.
While I was offline and you guys were debating the semantics, I was able to
get a rudimentary microcoded machine running, using the Pentium II as the
microengine. A "jmp _at_$xxx" takes 4 Pentium opcodes. I also have demonstrated
the principle of emulating an I/O location by using an access violation to
trap to an I/O emulation routine. The I/O emulation routine modifies the
saved context of the CPU emulator, then returns from the trap. The
preliminary demos were done in a Windows Console environment, using Win32
memory management and the __try and __except mechanism.
My take on this debate:
Many of the characteristics of what we have traditionally considered
"microcoded architectures" were dictated by the economics and performance
limitations of contemporary logic resources. For example, the wide
instructions, fixed opcode formats, and the one-to-one mapping of
instruction fields to multiplexer controls, were all expedients to save
pennies and nanoseconds. The presence or absence of these limitations does
not qualify or disqualify an implementation as "microcode".
Many characteristics of micro-engines are also present in RISC
architectures, including jump delays and load delays. Writing assembly
language on a RISC machine that has a jump delay is nasty. Writing for a
machine that has a load delay is even nastier. When we did a RISC on a chip,
we decided to lay down more gates and slow things down to get rid of the
load delay. In any case, having these characteristics does not make a
machine a microengine, nor the software running on it microcode. It's simply
an economic/performance tradeoff that shows up in certain architectures.
Speed doesn't make the difference. Many modern emulators (simh, E11) are
faster than the original hardware.
You could theoretically take a 2901/2910 based platform and implement either
a hard drive controller or a CPU on it. In the first case, you would call
the program "the disk controller firmware", in the second case, you would
call it "the PDP-11 microcode". The platform does not make the software
microcode, the purpose of the software does.
Every microcoded machine is an emulation. A PERQ hardware platform running
PERQ microcode is a PERQ emulation, a PERQ running PDP-11 microcode is a
PDP-11. They are both emulations. They are both microcoded.
The thing that makes an CPU architecture what it is, is the programmer's
model. This environment is sometimes created in raw hardware, and sometimes
it is created by implementing an emulation. If the emulation runs on bare
hardware, and has exclusive control of that hardware, I would consider it
legitimate to call it microcode. If the emulation runs under a software
environment (Windows) and uses software resources (the file system), I would
call it an emulator.
What if you are developing "microcode" on a hardware simulator, such as a
software based simulator or an IKOS box? Do you not call it microcode until
you actually blow the ROMs and plug them in?
A lot of the terminology was squishy to begin with, whether we knew it or
not, and has morphed over the years. What you consider "bare hardware" or an
emulation can always be debated. I would in any case defer naming rights to
the implementor.
Microcode: the software that maps a CPU architecture onto a hardware
platform, where that software has exclusive and direct control over the
hardware.
--
Jonathan Engdahl???????????????? Rockwell Automation
Principal Research Engineer????? 24800 Tungsten Road
Advanced Technology????????????? Euclid, OH 44117, USA
Euclid Labs????????????????????? engdahl_at_cle.ab.com 216-266-6409
Received on Mon Sep 24 2001 - 13:01:06 BST