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

[Bob Supnik]

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.

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).

On 12/6/2016 12:00 PM, simh-request at trailing-edge.com wrote:
> Message: 1
> Date: Mon, 5 Dec 2016 12:05:39 -0500
> From: Paul Koning <paulkoning at comcast.net>
<snip>
> This makes me wonder about the fuzzy line between quirky features and sort-of-bugs.  The code snippet you mentioned sounds like it falls on the side of the "quirky", and it sounds right for the simulator to implement that.  On the other hand, there's one I recently read about a machine in which a subroutine call instruction would fail with the stack pointer equal to -0, but when the stack pointer was +0 it would produce an address error only for some of the addressing modes.  "The schematics ... confirm this; the reason is unknown" says the article.  Implementing that sort of corner case is obviously doable, but not necessarily all that useful.
>
> 	paul
>
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 6 Dec 2016 17:12:00 +0100
> From: Pontus Pihlgren <pontus at Update.UU.SE>
<snip>
> Are you suggesting that simulators should fix "bugs" for someone using a
> simulator for comparison when restoring real hardware it could be very
> confusing.
>
> (not that such comparisons should be truated anyway)
>
> /P
>