21 Feb
2018
21 Feb
'18
1:48 p.m.
On Wed, Feb 21, 2018 at 11:24 AM, Guy Sotomayor Jr via cctalk <
cctalk at classiccmp.org> wrote:
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
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.