Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!sun-barr!oliveb!tymix!tardis!jms
From: jms@tardis.Tymnet.COM (Joe Smith)
Newsgroups: comp.sys.amiga.tech
Subject: Re: address spaces
Summary: many many
Keywords: virtual memory, address space
Message-ID: <247@tardis.Tymnet.COM>
Date: 10 Jun 89 00:48:10 GMT
References: <377@xdos.UUCP>
Reply-To: jms@tardis.Tymnet.COM (Joe Smith)
Organization: McDonnell Douglas Field Service Co, San Jose CA
Lines: 42

In article <377@xdos.UUCP> doug@xdos.UUCP (Doug Merritt) writes:
> ... Quaint notions
>of fixed numbers of address bits, small fixed numbers of address spaces,
>small fixed numbers of addressing capabilities/protections, etc, will
>all eventually disappear, not long after non-von-neumann architectures,
>object oriented architectures, hardware garbage collection, and architectural
>support for dynamic data structure shaping are taken for granted rather than
>being novelties. I figure on seeing this around the time that optical logic
>starts replacing GaAs (unless nanocpu's get there first).
>Doug Merritt		{pyramid,apple}!xdos!doug
>Member, Crusaders for a Better Tomorrow	Professional Wildeyed Visionary

Parts of this prediction are already here.  BiiN (formed by Intel + Siemens)
has a system with 2**26 address spaces.  Any of which can be shared or
private, at the programmer's whim.  A process can ask the OS to create an
address space which refers one structure in an array of structures, and
then pass an Access Descriptor (pointer) of this limited address space to
another process.  Even if the second process is buggy, and tries to write
at random offsets from the pointer, the first process is protected since the
hardware limits what the second process is allowed to access.  

Implementations along these lines have much more than just pointers to char,
int, double, etc.  A "pointer to file" has meaning to the hardware page table.
(Functions such as lseek() become superfluous with memory mapped files.)

But back to the present Amiga discussion:

I grew up with an OS that has private address spaces so that process A cannot
meddle with process B, maliciously or accidentally.  In fact, process A cannot
even see process B's address space unless they both issue calls to the OS
to grant shared access.  

The first step that I think most of us would agree on is to make the shared
libraries be read-only (and provide a mechanism to allow a library to tell
the exec that is wants temporary read-write access to its private structures).
This will prevent problems such as a random pointer wiping out part of the
FastFileSystem (code or data) and wiping out your hard disk.
-- 
Joe Smith (408)922-6220 | SMTP: JMS@F74.TYMNET.COM or jms@tymix.tymnet.com
McDonnell Douglas FSCO  | UUCP: ...!{ames,pyramid}!oliveb!tymix!tardis!jms
PO Box 49019, MS-D21    | PDP-10 support: My car's license plate is "POPJ P,"
San Jose, CA 95161-9019 | narrator.device: "I didn't say that, my Amiga did!"