From: utzoo!decvax!duke!harpo!eagle!mit-vax!tjt
Newsgroups: net.micro.68k
Title: Re: UNIX onthe 68000
Article-I.D.: mit-vax.159
Posted: Mon Aug  2 08:16:51 1982
Received: Tue Aug  3 01:22:56 1982


68000 systems that use a second processor to handle page faults while the
first processor is in a very long memory wait can (or should) be able to
handle arbitrary page faults (i.e. there should be no reason why only
data or only program references would work).  The catch is that with the
dual processor scheme, there is nothing else you can do during a page
fault (except field interrupts -- provided the hardware allows the second
processor to handle interrupts when the first processor is stalled).
In particular, the first processor cannot run code for another process
since the paging stunt depends on that processor hanging in a memory cycle.

Depending on how independent the second processor is, you may be able to
get other useful work out of it when it isn't handling a page fault (I believe
that Apollo uses a second processor to handle the network and some graphics),
but in order to do this effectively it would need some memory of its own
(or else some very fast system memory).  The problem is that a 68000 is
basically a memory-limited machine (most internal clock cycles are used
for memory cycles), and are often faster than system memory (i.e. wait states
are required), so there isn't any extra bandwidth for a second processor
to run without drastically interfering with the first.

The limitation on page fault handling imposed by the second processor should
not be too big a problem on a single user system, although ambititous
UNIX users can easily generate several active processes (i.e. edit in
foreground with a compilation in the background), but would obviously have
a chilling effect on time sharing.