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

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 @$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(a)cle.ab.com 216-266-6409