Writing emulators (was Re: VCF PNW 2018: Pictures!)

[Paul Koning]

> On Feb 21, 2018, at 2:24 PM, Guy Sotomayor Jr <ggs at shiresoft.com> wrote:
> 
> 
> 
>> On Feb 21, 2018, at 10:59 AM, Paul Koning via cctalk <cctalk at classiccmp.org> wrote:
>> 
>> 
>> Caching doesn't change user-visible functionality, so I can't imagine wanting to emulate that.  The same goes for certain error handling.  I've seen an emulator that included support for bad parity and the instructions that control wrong-parity writing.  So you could run the diagnostic that handles memory parity errors.  But that's a pretty uncommon thing to do and I wouldn't bother.
> 
> I disagree, especially if you’re using an emulator for development.  Caching is one of those things that can go
> horribly wrong and not having them emulated properly (or at all) can lead to bugs/behaviors that are significantly
> different from real HW.  The same goes for error reporting/handling.  There are cases where errors may be expected
> and not having them can cause the SW to behave differently.

Yes, there may be cases where errors are expected.  For example, out of range address errors, which are used by memory size probing.  But wrong-parity errors are far less likely.

I saw it emulated on Dick Gruene's EL-X8 emulator, and tested by the associated test program he wrote (which compared bare-metal execution of the test program with execution of that same program on the emulator, just like what Ray suggested).  There is a CWI report that describes this, its pretty neat.  But apart from testing the compleness of his understanding and the emulation of the "write wrong parity" instruction, it didn't really add anything useful to any other software.  No OS or application I have found depends on that capability, so our SIMH based emulator omits this and no harm is done by that omission.

>>> ...
> 
> However, it is my belief (and I think others have also stated) that assuming infinitely fast I/O (e.g. no delays what so ever) can cause issues because in many cases the SW expects to be able to do some work between the time that the I/O is started and when it completes.

True, that is unfortunately a fairly common type of software bug.  And because it is, emulators have to work around those bugs.  I make it a point to call it a bug, though, because I don't want anyone to get the impression that OS programmers who wrote such things were doing the right thing.

	paul