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

[Charles Anthony]

On Wed, Feb 21, 2018 at 11:24 AM, Guy Sotomayor Jr via cctalk <
cctalk at classiccmp.org> 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.
>
>
dps8m caught a lucky break here; neither the memory or page table caches
are needed for Multics to run correctly. (To some extent due to the
existence of cache disabling switches on the configuration panel.)

The diagnostics do extensive testing of the caches, and (unusually for the
project) they are well documented; the cache emulation code is a build-time
configuration option, and passes the diagnostics tests albeit with a
significant performance hit.

-- Charles