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

Reply via email to