16 Jul
2019
16 Jul
'19
11:44 p.m.
On 2019-07-16 23:38, John Forecast wrote:
I think field service might have had one as well, but it might also have
been a later combination of the other two.
You might be amused to hear that CASTOR:: and POLLUX:: were later
disassembled and moved, and reemerged in Colorado Springs, and was named
PHEANX:: and was kept running until approximately the year 2000, when it
developed a hardware problem that was not considered worth fixing.
By now I'm sure all bits and pieces have been lost. :-(
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
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. 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).