Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!leah!bingvaxu!sunybcs!ugkamins
From: ugkamins@sunybcs.uucp (John Kaminski)
Newsgroups: comp.sys.amiga
Subject: Re: MMUs and Re: inconsistent gadget function parameter ordering
Message-ID: <5721@cs.Buffalo.EDU>
Date: 6 May 89 20:04:30 GMT
References: <7989@killer.Dallas.TX.US> <6752@cbmvax.UUCP>
Sender: nobody@cs.Buffalo.EDU
Reply-To: ugkamins@sunybcs.UUCP (John Kaminski)
Organization: SUNY/Buffalo Computer Science
Lines: 27

In article <6752@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes:
=>...  This would still be a linear address space, and would count
=>on program's properly allocating this PUBLIC and PRIVATE memory (eg, I
=>doubt that MEMF_PUBLIC is respected well enough for that to be sufficient).

The whole idea of this task protection stuff is to save the rest of the system
from the laziness/flakeyness/viciousness of other tasks.  Right there you seem
to defeat yourself.  You can't count on a task to properly do anything.
The only two ways I know to provide true protection of
something from everything else are: 1.) special hardware that limits one task's
access to everything on the system, except maybe itself, or 2.) create your
own virtual machine--if you wanted to, you could model the 680x0 in software,
with additional code thrown in to maintain control.  #2 is really just a
software solution of #1.  In other words, if you emulate a processor, or just
simply make up your own, you have total control of what goes on; if you don't
want something in a particular address to be there, you simply make it
impossible for it to happen.  This is something akin to being a microcode
programmer.

---
a-WYSIWYG, a-WYSIWIG
a-WYSIWYG, a-WYSIWIG
a-WYSIWYG, a-WYSIWIG
a-WYSIWYG, a-WYSIWIG
In the jungle
The silicon jungle
The process sleeps tonight