Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ucbvax!CORY.BERKELEY.EDU!dillon
From: dillon@CORY.BERKELEY.EDU (Matt Dillon)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Address Space on the Amiga (was Re: Need info on exceptions)
Message-ID: <8808311759.AA19249@cory.Berkeley.EDU>
Date: 31 Aug 88 17:59:56 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 45


	Actually, the address CAN be a virtual address if you use a linear
address space for all tasks.  That is, if task A has some pointer variable
X which it passes to task B, task B can reference that pointer without 
translating the (pointer) value of X... B might need PERMISSION to do so
via its page table, but the keyword is 'NO translation required'.

	This does not mean that X must point to physical memory, just as long
as the MMU MAP is to a unique address, see?

	Thus, you can give processes access to each other's memory on a 
per-process basis, and even though this is restricted to the page size of
the MMU, it is still better than no protection at all.  Specifically, a 
task would be able to say "This is protected and nobody but me can access it".

	For example, if you allocate stacks in multiples of the page size,
you can put one or more unmapped pages at both ends of your stack space and
thus trap any stack overruns or underruns that occur.... hell, you could put
a 32K dead space on either end if you wanted because with an MMU one has 
the entire address space to put things in. 

	Then we get to keep our IPC message-pointer passing model and go FAST
PLUS HAVE MEMORY PROTECTION all at the same time.  Gee Wiz (sarcastic smiley).

					-Matt

:: [somebody besides Matt writes]
::				An idea central to the Amiga
::is that an address in any tasks address space is not a virtual 
::address but a physical memory address. That means that you can hand 
::a pointer off to another task and it will be valid in THAT tasks's address
::space.
:	Yes, this *IS* a nice idea.
:>>Personally I think this is the single biggest problem with the Amiga.  
:
:	Well, in some ways it's one of it's biggest wins, as well.  It makes
:for VERY fast (but simple) IPC, which the OS relys on heavily.  Removing that
:from the OS would make it grind to a (comparitive) halt.
:
:	Overall, this hypothetical OS would be more resistant to crashes,
:though not 100%.  Drivers and handlers would have to be trusted.  Libraries
:
:	The FAST bit is the important bit.  memory allocation is slow,
:and so is copying, especially when you're dealing with bitmaps...  :-(

			-Matt