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, [email protected] wrote:
Message: 1
Date: Mon, 5 Dec 2016 12:05:39 -0500
From: Paul Koning <[email protected]>
<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 <[email protected]>
<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
_______________________________________________
Simh mailing list
[email protected]
http://mailman.trailing-edge.com/mailman/listinfo/simh
