Re: Proposal to drop MKCATPAGES

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Sun, 25 Oct 2020 16:22:33 -0400
    From:        Thor Lancelot Simon <tls%panix.com@localhost>
    Message-ID:  <20201025202233.GA15915%panix.com@localhost>

  | Was the Australian machine kre mentioned one of those bizarre dual-68000
  | designs that ran two CPUs in lockstep to handle non-restartable
  | instructions?

No.

It had memory management implemented in the memory boards, rather than
by something near the CPU - all addresses on the bus (VME, or something
close to it) were virtual, the memory boards responded to an access if
they contained a page with a mapping that matched the address on the
bus.   It used address space ids so every mapping for every page didn't
need to be updated every time there was a context switch (just the current
process id on every memory board).   Needless to say the memory was very
slow (LOTS of wait states).   The processor was a 68020 I believe (though
there might have been some 68010 versions at one stage).  No caching.

I was (fortunately) not involved in the software for it, beyond some
hardware testing, so I'm not sure which underlying system it started
from.   It did all work, but was horribly slow (the systems tended to
also have some "normal" memory that worked only for the kernel, and
was physically addressed, and much faster).

kre

ps: I heard of those dual cpu 68000 systems too, but also never saw one.
"lockstep" was not quite right though, I believe, one cpu ran a cycle (or
a few) behind the other, so when the first one faulted, the other could
avoid executing the faulting instruction until after the cause of the
fault (that is, assuming it was a missing page) was fixed.   Actually quite 
clever.