Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!cbmvax!daveh
From: daveh@cbmvax.UUCP (Dave Haynie)
Newsgroups: comp.sys.atari.st
Subject: Re: Multitasking on the ST
Message-ID: <7720@cbmvax.UUCP>
Date: 21 Aug 89 16:46:47 GMT
References: <679@opal.tubopal.UUCP>
Organization: Commodore Technology, West Chester, PA
Lines: 25

in article <679@opal.tubopal.UUCP>, alderaan@tubopal.UUCP (Thomas Cervera) says:

> =The problem is that for instance a page fault can emerge whilst in the
> =middle of an instruction. 

>   I'm not that familiar with the 68000's hardware and pin configuration.
> But isn't there a pin telling the non-existent MMU 'shut up, I'm working on
> an instruction right now !' ?

Impossible.  It's the fact that the 68000's working on that instruction that 
caused the page fault in the first place.  Page faults are caused most often
on a VM system when an instruction tries to access a virtual address that 
isn't currently in physical memory.  This always happens in an instruction;
where else do you think addresses are generated?  The exception takes place,
the OS brings up its VM manager which proceeds to fetch the missing page, then
either continue the instruction (68010-68030) or retry the instruction (68040).
The 68000 doesn't save enough context for either.  Though back in the old
days, a pair of 68000s could be hooked up to achieve this same end (Apollo is
one company that used such a scheme). 

> Thomas Cervera         | UUCP:   alderaan@tubopal.UUCP       
-- 
Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests"
   {uunet|pyramid|rutgers}!cbmvax!daveh      PLINK: hazy     BIX: hazy
            We have no choice.  We are, after all, professionals.