> On Dec 6, 2016, at 1:14 PM, Bob Supnik <[email protected]> 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 _______________________________________________ Simh mailing list [email protected] http://mailman.trailing-edge.com/mailman/listinfo/simh
