🚀 go-pugleaf

Forwarded-For: robertb@june.cs.washington.edu (Robert Bedichek)

Tektronix developed an 88k simulator that they used to bring up a
system V kernel.  It is described in: 

"Some Efficient Architecture Simulation Techniques" by Robert Bedichek
published in the Winter 1990 USENIX Technical Conference Proceedings.

I recently made the simulator use gdb as its front-end instead of dbx.

Let me know if you are interested in using this simulator.  And if you
are, tell me what host you plan to run it on and for what purpose.
This will help me know what to do to the code so that it is usable by
others. 

It currently runs on the Tektronix XD-88 workstations running System
V.  It can boot the kernel to the point of a shell prompt, though I
haven't made the serial chip simulator generate interrupts yet (it did
when it was hosted on a 68k machine that ran BSD and thus had SIGIO).

I did a lot of the original simulator work while working at Tektronix.
I glued it to gdb on my own time, but using Tek resources (thanks Tek!).
This offering implies absolutely no support from Tek.  I do not
represent Tektronix.

Short feature list:

1. On a 20 MHz 68020, it used to run at 130,000 88100 instructions
   per second (on Dhyrstone).  It is now slower since memory breakpoint
   and stack limit checking were added, but it is still pretty fast.
   (On the XD-88, it takes about 40 seconds to boot the kernel in
   single-user mode, though the kernel skips zeroing of memory if
   it is running under the simulator.)

2. Gdb front end, so you can symbolically debug your 88k kernel, or
   whatever.

3. Extensive I/O section so that you can add I/O simulators easily.
   There are a number of devices that we already simulate.

4. Can set breakpoints and single-step code that runs with shadow
   registers frozen.  A real machine can't do this.  Exception
   handlers run for a while w/ shadows frozen.

5. Complete enough to run the System V kernel, although w/ an
   artificial disk.  But the timer chip, serial chip, and interrupt
   system are complete enough that the kernel can't tell the difference
   between the simulator and the real hardware.

6. Address trace facility for generating trace data for cache 
   simulation.  There aren't a lot of ways of getting accurate
   trace data for kernel and user code.  This is one of them
   and it doesn't require special hardware.

	Rob