Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!gatech!purdue!i.cc.purdue.edu!h.cc.purdue.edu!s.cc.purdue.edu!ain
From: ain@s.cc.purdue.edu (Patrick White)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Address Space on the Amiga (was Re: Need info on exceptions)
Message-ID: <3528@s.cc.purdue.edu>
Date: 31 Aug 88 21:54:47 GMT
References: <8808311759.AA19249@cory.Berkeley.EDU>
Reply-To: ain@s.cc.purdue.edu.UUCP (Patrick White)
Organization: PUCC Land, USA
Lines: 26

In article <8808311759.AA19249@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes:
>	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".

   Why not just have a separate virtual address space for each process's shared
memory, and have the pointers contain which task's virtual address sapce it is
for.. for those familiar with the 8086 architecture, I'm talking about
something similar to a separate segment for each task (I looked at the way the
8086 was done once, and decided that segements are a good idea, just not the
way intel implemented them).
   Of course, this won't work for the current 68000 architecture as it would
ideally be supported at the ucode level.

   For the current implementation, we could always make everyone use the
MEMF_PUBLIC flag and too bad for the people who were sloppy. :-).. it's really
the same kind of thing as happened with fast memory -- sloppy programs broke.


-- Pat White
ARPA/UUCP: k.cc.purdue.edu!ain  BITNET: PATWHITE@PURCCVM  PHONE: (317) 743-8421
U.S.  Mail:  320 Brown St. apt. 406,    West Lafayette, IN 47906
[let's all help Joe out... send your IFF pictures or music to joe@dayton.UUCP]