Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!motcsd!xdos!doug
From: doug@xdos.UUCP (Doug Merritt)
Newsgroups: comp.sys.amiga.tech
Subject: Re: MEMF_PHYSICAL?
Message-ID: <369@xdos.UUCP>
Date: 2 Jun 89 15:11:45 GMT
References: <8906010252.AA11810@jade.berkeley.edu> <367@xdos.UUCP> <3244@cps3xx.UUCP>
Reply-To: doug@xdos.UUCP (Doug Merritt)
Distribution: na
Organization: Hunter Systems, Mountain View CA (Silicon Valley)
Lines: 73

In article <3244@cps3xx.UUCP> porkka@frith.UUCP (Joe Porkka) writes:
>In article <367@xdos.UUCP> doug@xdos.UUCP (Doug Merritt) writes:
>>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
>
>Nope. It must *think* that it is at the same place in memory. MMUs can
>make an actuall block of memory at hardware address $cef3d appear to the

Right. But that doesn't make a difference, because once you do this,
you have gone and created separate address spaces already!

The fact that all of your tasks might *all* be loaded at the same virtual
address (and different physical addresses) means that you've already
given up the single address space model that I was arguing against.
The tasks may have *some* shared address space, but it is no longer
the simple "single address space".

To reiterate, you can't use the single address space model because it
would force loading (reloading/swapping) of tasks into a fixed physical
address, screwing up virtual memory management. The apparent fix of
making it a fixed *virtual* address instead means that you've given
up the idea of the pure single address space model. QED.

> [ ...description deleted...]
>If the info is not in memory, the MMU picks a chuck of memory to swap
>out. It gets written to disk, the needed block is loaded in is place,
>and the address mapping function is updated. Simple huh?

Overall, that was a nice description of how VM could work. And yes,
it's pretty simple.

>>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.

>Yes we can. Any program can read any address. The MMU makes sure
>the right thing gets back to the CPU. The MMU should also *enforce*
>protected areas, so that even though Program A can peek at Program B, it
>wont be allow to poke it.

Yes, you could do that. No, it won't be sufficient. It will prevent
message passing between cooperating tasks, because the memory needs
to be in shared read/write memory. If you write-protect AmigaDOS data
pages as well as user task pages, then you prevent things like installing
your own volume nodes, and in general you break all those custom hacks
like vscreen, backdrop, dropshadow, etc.

>>Because of this it just doesn't make sense to claim that a single address
>>space model is inherently superior to multiaddress space models. It
>
>Bah!

Monosyllabic pejoratives like this really detract from technical
discussions. Look, I may say stupid things, I may not see your point,
maybe we can figure out a way around the problems, but it's illogical
not to at least seriously consider what I say, simply because I have
experience with the subject. I've designed MMU hardware architecture
for real systems, I've implemented custom OS's, hacked Unix, and coped
with existing VM OS's (Unix and otherwise) as a user. This doesn't prevent
my making mistakes, but it does mean that I'm not totally ignorant of the
subject.

To assume that the person on the net you're arguing with is an idiot
who should be dismissed with terms like "Bah!" is to limit your own
information gathering resources. Sometimes a disagreement can be the
source of important new knowledge. Next time it might not be *me*
you dismiss, it might be somebody *really* smart! :-) :-)
	Doug
-- 
Doug Merritt		{pyramid,apple}!xdos!doug
Member, Crusaders for a Better Tomorrow		Professional Wildeyed Visionary

"Welcome to Mars; now go home!" (Seen on a bumper sticker off Phobos)