[Simh] Writing a simulator (was: Unit/functional testing simulators (Seth Morabito))

[Bob Supnik]

I've written extensively about creating new simulators. The SimH web 
site has an article about how to organize a simulator 
(http://simh.trailing-edge.com/docs/simh.pdf). As important, though, is 
the prework of gathering materials, which I talked about in an ACM Queue 
article a few years back. The WE family is not well represented in the 
Bitsavers archive. In contrast, when I did the PDP-1/4/7/8/9/15 
simulators, I had the maintenance manuals and the engineering drawings; 
when I did the PDP-11, the design specs and microcode for the J-11 (and 
engineering drawings and microcode for other models); and ditto for 
CVAX. Many a fine point or seeming bug has required looking at 
engineering drawings to resolve.

As a starting point, most simulator have a fairly stereotyped structure:

t_stat sim_one_inst ()
{
fetch an instruction;
extract the opcode;
evaluate operands if that is orthogonal to instruction execution and 
format;   //VAX, Interdata, for example
switch opcode {
    case opcode 0:
     :
    case opcode n:
     :
     }
process exceptions;
return status;
}

The core simulation engine can be built out one stub at a time and one 
instruction at a time, invoked through hand test cases or simple 
diagnostics. I find interactive debugging to be more useful than test 
scripts; that's why I develop in Visual Studio. Scripting comes later, 
when I want to automate running of diagnostics, major regression suites, 
or operating systems.

So my advice, for what it's worth, is to focus on research about the 
hardware, on understanding the hardware structure, and on modeling the 
hardware with reasonable accuracy. Perhaps some veterans of the original 
design team still retain design documents or microcode listings or 
maintenance manuals; any or all would help.

/Bob Supnik