On Tue, Dec 06, 2016 at 08:29:44PM -0500, Bob Supnik wrote: > Simulators should never fix "bugs". The question at issue is how deeply to > mimic them, in order to assure maximum compatibility with software.
My point exactly :) (Note that my question was directed at Paul). > > Over the years, I've concluded that straying too far from the hardware is > dangerous. I'm not suggesting that every register-transfer-level interaction > has to be there. It's okay to write > > IR = M[PC]; > > instead of > > MA = PC; > ReadM (); > IR = MB; Well, if you want to simulate a front panel you might want to. (I've written a fairly competent PDP-8 emulator as an excersize and am considering doing a software front panel showing MA, MB among the other registers) > But software often depends on "bugs". The routines that identify the models > of a PDP8 and a PDP11 are very dependent on 'bugs' (or incompatibilities, if > you prefer) between models. (And some of those incompatibilities are indeed > bugs, like the ASH/ASHC problem in the J11.) The IBM 709X's double precision > floating point divide is clearly rather inaccurate, but the simulator has to > reproduce the hardware algorithm bit for bit, rather than perform a modern > divide. > > Fixing, of if you prefer, improving, the way the hardware actually worked is > hazardous. In the original H316/H516 teletype code, I included lots of > rational checks to prevent switching the half-duplex interface between input > and output in "wrong" places. The actual logic had none of those checks, and > the checks broke the Teletype code in the IMP simulator. > Not premature optimization but premature error checking :-) Regards, Pontus. _______________________________________________ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
