Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!amdahl!terry
From: terry@uts.amdahl.com (Lewis T. Flynn)
Newsgroups: comp.arch
Subject: Re: Multics & Memory mapped files
Message-ID: <70Si02OM87QV01@amdahl.uts.amdahl.com>
Date: 10 Feb 90 21:06:21 GMT
References: <8859@portia.Stanford.EDU> <20571@watdragon.waterloo.edu> <49956@sgi.sgi.com> <4791@helios.ee.lbl.gov> <2093@crdos1.crd.ge.COM> <1990Feb7.221800.804@utzoo.uucp> <2106@crdos1.crd.ge.COM> <5180@crdgw1.crd.ge.com> <5684@blake.acs.washington.edu>
Reply-To: terry@amdahl.uts.amdahl.com (Lewis T. Flynn)
Organization: Amdahl Corporation, Sunnyvale CA
Lines: 17

In article <5684@blake.acs.washington.edu> mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) writes:
>
>Furthermore, I hope that no one would implement file/memory mapping
>that only mapped the entire file in.  You should be able to map n
>"pages" or "segments" from "page"/"segment" i of source to
>"page"/"segment" j of destination.

[ and a further discussion and detailed example.]

Another example is KeyKOS where the maximum segment is 2**47 pages (2**59
bytes) and the user could map into his address space any portion at any
location. This in an implementation on a harware architecture which only
allowed physical segments and address spaces of 2**24 bytes.

Terry

disclaimer: I have no idea what Amdahl's views are.