[HECnet] DECnet Implementation and Productization of RSX-11M, 11S, 11D and IAS (was Re: Anonymous FAL (Tops-20))

[John Forecast]

> 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]
>> 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).
> 
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.

> 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