[Simh] Simulator accuracy (was Re: New TC11)

[Paul Koning]

> On Dec 6, 2016, at 1:14 PM, Bob Supnik <bob at supnik.org> wrote:
> 
> I'm not sure there are any "non-quirky" standard operating conditions, unless they were unpredictable from system to system. For example, the implementation of interrupts on the RH series Massbus adapters is truly broken, but it has to be simulated accurately, or the workaround in the Unix driver fails. (I wrote a short paper on this.) The "unimplemented" opcodes in the H316/H516 need to be simulated correctly because some of them got used after programmers discovered what they did. For that matter, my former colleagues at Unisys got burned when it turned out than an "unpredictable" operation had had predictable results for several generations of systems, and customer code depended on that.
> 
> But perhaps erroneous error responses don't need to be accurately simulated. Rigel (the VAX chip used in the VAX6000-400) had a microcode bug that failed to fault on a specific reserved operand in INSV. Because every other VAX would simply crash the user's program in this case, the bug was waived and never fixed. It's hard to see how Paul's example could be exploited either.

If you want to dig deeper, the example I referred to is an EL-X8 simulator documented in CWI (Mathematisch Centrum) report MR141 (http://oai.cwi.nl/oai/asset/9135/9135A.pdf), in particular the items described in section 10.  There's fun stuff like the example I mentioned, or the fact that exceptions change several state bits as part of taking the exception vector -- but not all at the same time, or the fact that stack pointer increments omit the end-around carry in what's otherwise a one's complement machine.  With sufficiently clever test programs you can see these things, but none of these lead to any  interesting exploits nor are they behavior useful to any ordinary program.

> It is not at all farfetched to use a simulator as part of a historical restoration. When my friend in Australia was restoring a classic 8, he used the PDP8 simulator to construct and prove out small diagnostics for tracing specific logic paths. The 1401 restoration team at the Computer History Museum used the simulator as an aid in their work, although any discrepancy in behavior must be accounted for (and fixed in the simulator, if verified from the schematics).

That certainly sets a very high bar on the simulator.  I think at times you may run into issues that are outside the scope of the simulator.  For example, SIMH doesn't exactly simulate timing.  There might be timing dependent behavior that is too hard to handle.  I don't know of SIMH examples but there's a well known case in the DtCyber CDC 6000 series simulator.  One of the diagnostics fails because it relies on the exact timing of some of the instructions (exchange jump and divide, if I remember right).

	paul