Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!ccplumb
From: ccplumb@watnot.UUCP
Newsgroups: comp.sys.amiga
Subject: Re: Networking Amigas + MMU's
Message-ID: <12822@watnot.UUCP>
Date: Wed, 8-Apr-87 14:20:12 EST
Article-I.D.: watnot.12822
Posted: Wed Apr  8 14:20:12 1987
Date-Received: Sat, 11-Apr-87 05:23:54 EST
References: <8704080809.AA04117@cory.Berkeley.EDU>
Reply-To: ccplumb@watnot.UUCP (Colin Plumb)
Organization: U. of Waterloo, Ontario
Lines: 53

dillon@CORY.BERKELEY.EDU (Matt Dillon) writes:
>MMU on an Amiga:
>
>	An interesting thought.  Currently not feasible except perhaps as
>a protection mechanism or to implement virtual memory.  The VM would be
>limited to a general scheme for the whole machine rather than a 'per process'
>scheme used by UNIX (i.e. no duplication of addresses).   Implementing an
>MMU under the current Amiga enviroment would require resource tracking by
>the system.
>
>	Even so, you would *not* be able to implement page mapping (the
>"all programs start at the same address" model) since arbitrary programs
>will reference the same global structures (Windows/Screens/Libraries/Ports) and
>pass pointers to each other.

Indeed, using an MMU would require resource tracking.  This requires
considerable fiddling of AmigaDOS, but AmigaDOS requires considerable
fiddling already, so it's no great loss.

But address translation could indeed be added to the Amiga architecture.

I can't think of any application except debugging that requires access to
another process's *text* space.  (For non-Unix types, that's where the
machine code goes... you know, the stuff that's a pain to make relocatable.)
Anything Mem_Alloc'd can easily be made MEMF_PUBLIC (you *do* use that flag,
don't you?), and thus globally addressed by all processes.

Protection on public memory can be done in a variety of ways (maybe
just have it all R/W), but if protection is implemented, there should
be calls that can be used to say `let me write to public memory'.
(I think all of it together would be easier to use... assigning write
permission to sections is a pain.)  PopColours is difficult to write
otherwise.

There is, admittedly, one catch... libraries.  I'll have to look over the
interface to see if something can be done.  They could always be made
relocatable, but it would be nice not to have to.  How do other machines
handle shared libraries?

So, we can just divide 4 gig into quarters... private, (public) chip,
public fast, and mappable (for debuggers).

Even if you don't implement this, an MMU solves one great problem:
*fragmentation*.  You never have to reboot to fit a big file into
your machine.

Comments, anyone?  With MMU's on the way, a discussion on how to handle them
seems appropriate.
--
	-Colin Plumb (watmath!watnot!ccplumb)

Silly quote:
There's a dark cloud on every rainbow's horizon.