Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!uwvax!tank!eecae!cps3xx!usenet
From: usenet@cps3xx.UUCP (Usenet file owner)
Newsgroups: comp.sys.amiga.tech
Subject: Re: MEMF_PHYSICAL?
Message-ID: <3259@cps3xx.UUCP>
Date: 2 Jun 89 22:00:47 GMT
References: <8906010252.AA11810@jade.berkeley.edu> <367@xdos.UUCP> <3244@cps3xx.UUCP> <369@xdos.UUCP>
Reply-To: porkka@frith.UUCP (Joe Porkka)
Distribution: na
Organization: Michigan State University
Lines: 51

In article <369@xdos.UUCP> doug@xdos.UUCP (Doug Merritt) writes:
>In article <3244@cps3xx.UUCP> porkka@frith.UUCP (Joe Porkka) writes:
>>In article <367@xdos.UUCP> doug@xdos.UUCP (Doug Merritt) writes:
>
>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

No, you load each program at a unique virtual address space.
This would work the same as it does now, each task gets loaded into a
particular address, that cant change until it exits and gets reloaded.

Hmmm... I think we are not quite talking about the same thing
somehow. The way I picture it, VM with a single address space, and no
protection of any sort, would give the appearance to any programs
running in it that there is a lot more memory than there really is.
Instead of upgrading your A2500 from 2megs to 8, just install VM.

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

I do not understand why a program at virtual address X would always
need to be at a fixed real address Y. The only thing that needs to 
stay the same is the virtual address. To change the real address, say
when a block needs to be reloaded, just update the MMU tables.

After the system has been up for a while, each physical block of memory
is mapped into some virtual address, and there would be no appearent
(definitly not linear) correspondence between virtual and physical
addresses, but the MMU makes it look like it by translating the addresses
coming out of the CPU.

Note: this would be a problem for memory-mapped IO, since actuall
addresses are important then. The MMU would need to be informed enough
not to remap the IO space to someplace else.
>
[ much stuff deleted ]
>>Bah!
>
>Monosyllabic pejoratives like this really detract from technical
>discussions. Look, I may say stupid things, I may not see your point,

Sorry, no offence intended.

I have never worked with the insides of a VM system at all. I have not
even looked at documentation for an MMU like the '551, but I
thought that I had a good understanding of the works. Perhaps I'm
mistaken.
This is an example of a short .signature   jap@frith.cl.msu.edu