Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!rpi!masscomp!hank
From: hank@masscomp.ccur.com (Hank Cohen)
Newsgroups: comp.arch
Subject: Re: Historical architectural advances??
Summary: It wasn't Apollo it was MASSCOMP.
Message-ID: <61266@masscomp.ccur.com>
Date: 16 Oct 90 02:13:51 GMT
References: <8139@scolex.sco.COM> <1990Oct13.035313.174@ingres.Ingres.COM> <1990Oct13.200414.3523@motaus.sps.mot.com> <AGLEW.90Oct14222151@basagran.crhc.uiuc.edu>
Reply-To: hank@westford.ccur.com (Hank Cohen)
Organization: Concurrent Nippon Corp. - Tokyo , Japan
Lines: 26

In article <AGLEW.90Oct14222151@basagran.crhc.uiuc.edu> aglew@crhc.uiuc.edu (Andy Glew) writes:
>
>And the MC68000 didn't have virtual memory.  Not all instructions
>could handle page faults, etc.  It took a while before the 68000 was
>suitable for use as a "real machine".
>
>I trust everyone knows about the twinned 68000s used in early Apollos?
>One a cycle behind the other, so that it could pick up at a page fault?

Not early Apollos early Masscomps.   ( Of course Masswho or Whatcomp
always suffered from a lack of recognition.)
The first products from MASSCOMP used two 68000's one called the
Executor and the other the Fixor.  The fixor was mostly idle until a
bus fault occurred at which time it would wake up and examine the
state of the executor and try to make things right again by bring in
pages and updating the MM (the MMU was a MASSCOMP design.  As a
previous poster noted Motorola didn't have one yet.)
Later releases of the OS implemented
floating point emulation on the fixor and when we got 68010s the
executor could save the state of the faulted process and continue
doing something else while the fixor made the world safe for virtual
memory again.  That was a big improvement since the 68000 executor had
to wait for page-ins and was therefore horribly slow and unreliable
for really big processes.

Hank Cohen