Path: utzoo!attcan!uunet!cs.utexas.edu!rutgers!apple!oliveb!amiga!cbmvax!jesup
From: jesup@cbmvax.UUCP (Randell Jesup)
Newsgroups: comp.sys.amiga.tech
Subject: Re: MEMF_PHYSICAL?
Message-ID: <7039@cbmvax.UUCP>
Date: 2 Jun 89 01:58:00 GMT
References: <8906010252.AA11810@jade.berkeley.edu> <367@xdos.UUCP>
Reply-To: jesup@cbmvax.UUCP (Randell Jesup)
Organization: Commodore Technology, West Chester, PA
Lines: 93

In article <367@xdos.UUCP> doug@xdos.UUCP (Doug Merritt) writes:
>There is no particular advantage to having a single address space if protection
>keeps you from writing outside of it, e.g. to system structures, so the
>distinction between the protection model and the memory model that you
>keep making is pointless.

	Single address space and protection are seperate issues.  Another
thing to realize is that protection doesn't necessarily mean protection
from another process reading your memory.  With one address space, you can
read lists and structures owned by different processes, which makes message
passing with pointers work much better.

>Another strong disadvantage of a single address space model is that it
>has problems regarding addressing. Let's say I run two programs,
>say for the purpose of having two copies of the same chess program play
>against itself. The Amiga simply relocates each copy to a different
>piece of allocated memory (patches each process to address correctly
>relative to its load point). But once that's done, each must always reside
>in that particular piece of physical memory. This puts a severe restriction
>on virtual memory, since each time one of those tasks is run, the same
>physical ram must be freed again, which will often mean that whole
>processes will *have* to be swapped out, while if private address spaces
>were implemented, then we'd be free to put it anywhere in physical ram
>we want.

	Wrong.  The whole point of VM is that the addresses can be mapped.
A single address space merely means that all processes share a single
mapping of virtual->physical.  Your hypothetical situation only arises
if processes can have different mappings.

>For real time programming, the performance advantage of shared address
>spaces makes them desirable, and hence the single address space model
>we have on the Amiga is a blessing. It is a mixed blessing nonetheless,
>since any malfunctioning program can bring down the whole machine.

	Protection (if implemented - various historical things make this
tough) would solve most of this, with a single address space.

>We can't (cleanly/simply/fully) introduce such a model to a new rev of
>the Amiga hw/sw because the system is committed to use of shared memory
>for message passing and for modification of system structures.
>
>Thus, despite the advantages of the Amiga approach, it also has some
>severe inherent design problems that lead to the machine crashing when
>some task goes bad.

	We cannot ever make it impossible, but we can cut way down on the
probability of it for MMU-based machines.  There's nothing we can do for
68000-based machines (which is almost all our installed base, though the
number of '020/'851 and '030 machines is definitely increasing.

	In fact, protection is by far most useful for developers.

>No matter how someone justifies it, this is not desirable, and it is an
>excellent reason for other systems using private address spaces by
>default. There are very effective real time systems that do this, and
>that allow tasks to share address spaces *by special request*, and under
>controlled circumstances that will not crash the machine. Even the tasks
>that need inherently dangerous access to hardware resources can be
>managed by limiting such access to "trusted" tasks, rather than allowing
>all programs such access, whether they need it or not.

	However, this is not an option on 68000 machines, and even on MMU
based machines it can greatly increase the overhead.  This has nothing to
do with single-address-space, though.

>I disagree, at least in part, but that's another issue. (Ok, briefly:
>what about those who have said they'd like to have both AmigaDOS and
>Minix running at the same time!?)

	Virtual machines are an amusing idea, and can be useful for debugging
OS's (slowly) on fairly generic machines, but the killer is hardware access.
You can only safely give I/O hardware access to the main OS, and any 
virual machines running become very problematical when they start trying to
twiddle hardware registers and get results.  You either have to have simulators
for every piece of hardware, or trap the low-level OS I/O routines for the
virtual machine and pass them to the main OS.

	You could write a minix kernel that ran UNDER exec/intuition/etc, and
BESIDE AmigaDos (see Devin's an my long exchange for more info).

>No, it is a requirement *for some tasks*, not for *all* tasks to share
>a single address space. As I said before, you get the maximum advantage
>of virtual memory management if most tasks are in private memory, and
>if it is an option to allow any two given tasks to share (some part of
>their) address spaces. The phrasing is confusing, I suppose, since I
>meant that it is a requirement to have the option!

	VM and single address space and protection are ALL seperate issues.
The only thing they have in common is that they involve the MMU.

-- 
Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup