Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!tank!uwvax!puff!cat28!blochowi
From: blochowi@cat28.CS.WISC.EDU (Jason Blochowiak)
Newsgroups: comp.sys.apple
Subject: Re: Re: multitasking, softswitch, etc.
Keywords: Multitasking, MMU, //gs
Message-ID: <2533@puff.cs.wisc.edu>
Date: 7 Apr 89 16:36:53 GMT
References: <8904041319.aa17266@SMOKE.BRL.MIL>
Sender: news@puff.cs.wisc.edu
Reply-To: blochowi@cat28.CS.WISC.EDU (Jason Blochowiak)
Organization: U of Wisconsin CS Dept
Lines: 47


	As I understand it, a MMU monitors what addresses are accessed by the 
CPU - this way, each process has a set of boundaries as to what memory it can 
access, so if it tries to write to some other process' memory, the MMU prevents
it (and flags it in some way). Because of this, even if one (user - I'll 
explain this in a bit) process goes haywire, it won't screw up other processes.
This makes a multitasking system more reliable. Also, on some processors (e.g. 
The 68000 - I'm not familiar with bunches of other processors), there are 
separate "user" and "supervisor" (or "system") modes - this makes it possible 
to protect some memory locations from being toasted by a user (non Operating 
System) program, so that a user program can die without screwing the system up 
(basically a limited form of what the MMU does). Anyways, if a system process 
(part of the operating system) makes a mistake (and I've yet to see an OS 
without bugs), the whole machine can go crashing down (if the mistake is large 
enough).

	Getting back to the //gs - it has no MMU, so there's no way to
guarantee that one process isn't writing to some other process' memory space.
What you were talking about (simulating a MMU in software) is possible, but not
practical, and, unless I'm missing something, probably not terribly useful. The
most straightforward way of doing it would be to have something that runs
perodically which verifies memory belonging to a particular process. So, while
process #1 is running, the verifier checks to see if the memory belonging to
processes #2 and #3 gets changed, and while process #2 is running, the verifier
checks to see if the memory belonging to processes #1 and #3 gets changed. Same
goes for when #3 runs (assuming there are only 3 processes going). Now for the
problems: Doing the checking in a reasonable amount of time would be REAL
tricky - either one does it by chunks, or one does it by checking the whole
thing at a time. The first option (chunks) would take awhile before a violation
would be noticed (a violation is a situation in which one process writes into
the memory of another), kind of missing the point of the whole thing. Checking
the whole thing at once would take gobs of time (inefficiency to the point of
uselessness). And then, on top of that, violations would be detectable, but not
preventable, which would mean that the system wouldn't be much more reliable
than it was without the verifier...
	This does not mean that multitasking is not possible on a //gs - this
means that SECURE multitasking is not possible with the //gs the way it is.
	Short answer: Good idea, but I don't think it'd work.
	
	Jason.
p.s. This is terrific, both my recent messages were negative - oh, well, I hope
they've been of some use to someone out there...

 ------------------------------------------------------------------------------
		Jason Blochowiak (blochowi@garfield.cs.wisc.edu)
			"Not your average iconoclast..."
 ------------------------------------------------------------------------------