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.