Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!noao!asuvax!behemoth!mph
From: mph@behemoth.phx.mcd.mot.com (Mark Huth)
Newsgroups: comp.sys.amiga
Subject: Re: OS/2 vs AmigaDOS
Message-ID: <10848@behemoth.phx.mcd.mot.com>
Date: 4 May 89 23:49:22 GMT
References: <16952@usc.edu> <7988@killer.Dallas.TX.US>
Reply-To: mph@behemoth.UUCP (Mark Huth)
Organization: Motorola Microcomputer Division, Tempe, Az.
Lines: 76

In article <7988@killer.Dallas.TX.US> elg@killer.Dallas.TX.US (Eric Green) writes:
>  ... (Stuff about virtural memory not being the same as process
protection)...
>So if your idea of heaven is to have a 10 megabyte RAD: device, and
>keep Excellence, X-WIndows, Superbase, and a half dozen other programs
>all running at the same time with no fear of running out of memory,
>you'll love what's coming. On the other hand, if your idea of virtual
>memory includes process protection, you're just plain out of luck.
>
Well, I guess I might as well wade into this MMU discussion.

The 68851 MMU used on the 2620 (and a subset of which is contained on
the 68030 - mostly fewer Address Translation Caches) provides several
different functions.  The functions provided are logical address to
physical address translation, segment/page write protection, and
privilege ring access protection.

The address translation function is what is needed to support
virtual memory systems.  Using the 2620 hardware, virtual memory could
probably be grafted onto AmigaDOS quicly and transparently.  About all
it would require is a mapper running in the Buss Error Exception
Handler, and a hook to turn on the MMU with an initial page table.
The OS and applications could all continue to reside in one large
virtual memory space, giving the Amiga a virtual memory about the size
of the hard drive. Actually, the memory space could be the entire 4GB
68020 space, but you could only use as much as would fit on the paging
device at any one time.  This wouldn't provide any protection, but it's
relatively simple to add the an existing system.  It could be done
without the source to the base OS.

It is possible to get some real protection using the page descriptors.
The page tables allow rather arbitrary mappings of memory, so it is
possible to fix areas of memory to not be visible from user space.  In
fact, the PMMU has three root pointers that allow separate translation
trees for user, supervisor, and dma operations.  A rapid context
switch is supported by simply changing the user root pointer when a new
process is dispatched.  Other users' physical memory may simply be
not appear in the translation tables.

Additionally, user data space and program space are separated, making
it a simple matter to protect code space from the user.  There is also a
write protect bit in each of the segment or page descriptors, allowing
read only access to certain areas of memory.

While relatively straight forward, the above protection would require
considerable modifications to some of the OS routines.  Most notable,
the memory management routines would need to change to allocate the
proper page table entries as well as the physical memory.  Also, it
would be necessary to change the calling sequence to system functions
and libraries to use a trap mechanism in order to get to supervisor
mode.  To add protection would require source code to the OS.

An additional level of protection can be implemented using the PMMU.
This is a ring protection scheme similar to the one found in Multics.
There are read and right access level registers for each page, and the
high-order bits of the address are used to determine the access level
requested.  There is aregister in the PMMU for the current task access
level.  This all works to provide rings of protection in the user
space.  To implement this sort of protection scheme would require a
rewrite of many portions of the system, possibly including linkers and
loaders, as the access information is encoded in the addresses.  This
type of protection is not normally needed in single user systems, but
is nice when the question of shared data is involved.

In summary, virtural memory in say a month, protection in 6 months to
a year, and anything more, well, why bother.  Note that protection
will eliminate the source of many gurus, but may not allow the resource
recovery that is needed to effectively kill an errant task.  That
would require that the OS have the necessary tracking mechanisms built
into it, and I'm not sure that AmigaDOS does enough in this area.

By the way, the above is a very brief summary of the 68851.  It's a
very complex chip - microprocessor-like complexity.  I've read the
manual a few times and still don't understand all of its subtleties.

Mark Huth