16 Jul
2019
16 Jul
'19
11:38 p.m.
On Jul 16, 2019, at 2:46 PM, John Wilson <wilson at
dbit.com> wrote:
From: John Forecast <john at forecast.name>
[E11 on MIM]
I suspected that was the case, but I just wanted to check. I wanted to run a
comparison test
between cache bypass on for all CEX code and selectively flushing the cache at strategic
points through
the code. What we ended up with was ~11/45 performance for the kernel code and ~n * 11/70
performance for the application level code. Since there were only a couple of mP machine
left (our dual
and the RSX-11M+ quad), it wasn?t worth the extra work.
John.
Does the simulator actually simulate the caches
or just the control registers
like SIMH?
Just the control registers. I hate doing an emulation of a speed-up
feature which actually slows it down (which is the case with the FASTBUS:
emulation for dual PDP-11/45s but there was no way around that -- making
the memory inherently mP-safe meant dinking with locks on every access,
so it's *much* slower to touch it than non-"FAST" core).
It might be interesting to do as a SET CPU option
though, for testing how
code would behave in nasty cases on a real 11/74. The fetch/decode/dispatch
loop and the most common instructions are recompiled (from scripts) on every
SET CPU command, so options like this can be added without penalty, as long
as they're disabled by default. It'd be pretty painful though, since in this
case *anything* that touches memory would have to be compiled at runtime,
so it'd be a lot more code than it is now (less common instructions are
static and check the SET CPU flags themselves on the fly rather than having
their behavior hard-coded into the compiled code).
John Wilson
D Bit