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

From: Jonathan Engdahl <engdahl_at_cle.ab.com>
Date: Fri Sep 14 18:03:50 2001

> > Another approach would be to view a Wintel
> > PC as a microcoded platform, and reimplement the PDP-11 on that
> hardware.
> > The microcode would be written in tightly crafted Pentium code. The
> machine
> > would bootstrap itself by loading the microcode from a special
> partition
> on
> > the hard drive.
>
> Why not burn it into (EP)ROM? 64K for the opcode jump table fits in a
> 27512, you maybe want about the same again for the code, and that
> would fit
> in some devices used for BIOS ROMs these days. Or put it on a SIMM or
> DIMM.
>
> --
> Pete Peter Turnbull
> Network Manager
> University of York



That actually was my first idea. That way, the hacked PC would be almost
indistinguishable from a real PDP-11. The hard drive would contain an exact
image of a PDP-11 disk, with no underlay of PC-ish partitioning.

But I'm not sure how much ROM space is available on modern PC mainboards.

I was thinking of using some extravagantly memory-wasting techniques to
speed things up. I would assign one x86 register to each PDP-11 register.
R0==BX, R1==CX,... R7==SI, etc. Opcode dispatch would be something like:

        lodsw ; ax=*si++
        jmp [ax*4+table] ; goto *table[ax]

The most commonly used execution routines would be just a few x86 opcodes,
followed by a dispatch. For example, the emulation of "mov (r1)+,r0" would
be:

        mov bx,[memory+cx] ; mov (r1)+,r0
        inc cx
        lodsw ; dispatch next
        jmp [ax*4+table]

You can probably tell my x86 coding skills are really rusty. Most of my x86
programming has been either on an 80188 (many years ago) or in C. But, you
get the idea.

With 65536 separate execution routines to write, you would probably want to
write a special code generator in C to write the emulator for you. Basically
a fancy macro processor.

In the example above, if R1 happened to point to an I/O register, don't
worry -- the i386 MMU has been set up so that this reference will trap. The
trap routine will look at the address that caused the trap, and dispatch the
appropriate I/O device emulator. The key is, let the MMU worry about I/O
references -- the CPU emulation just worries about the CPU.

Lots of detail unresolved: condition codes, for example. My suggestion,
forget about them until you get to a branch instruction. Use the native x86
condition codes. The architectures are probably sufficiently similar. In the
example above you might have to insert "and bx,bx" or whatever the x86
equivalent is after the MOV to set the condition codes PDP-11 style. (I
think MOV sets the N and Z flag, right?)

I haven't thought about this on paper yet, so I don't know how feasible it
would be. I tremble at the thought of having to program the i386 protected
mode. I tried it once years ago, and gave up. It's pretty messy. You'd also
have to be very familiar with the PC bare hardware, which I am not.

--
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 Fri Sep 14 2001 - 18:03:50 BST

This archive was generated by hypermail 2.3.0 : Fri Oct 10 2014 - 23:34:25 BST