> On Feb 21, 2018, at 2:24 PM, Guy Sotomayor Jr <g...@shiresoft.com> wrote:
>
>
>
>> On Feb 21, 2018, at 10:59 AM, Paul Koning via cctalk <cctalk@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
