Article View: comp.unix
Article #417Re: UNIX Facilities for Interpreters
From: Larry Campbell
Date: Tue, 30 Jun 1987 00:58
Date: Tue, 30 Jun 1987 00:58
44 lines
3003 bytes
3003 bytes
In article <881@mcdchg.UUCP> boba@iscuva.ISCS.COM (Bob Alexander) writes:
>Modern, memory managed operating systems (like UNIX) have addressed ...
UNIX isn't particularly modern -- it's 15 years old -- and memory
management was tacked on as an afterthought, not designed in.
(Otherwise I'd never be able to run it on my 8088!)
Bob goes on to lament the fact that data can't easily be shared among
UNIX processes and proposes a new system call to allow this. I would
like to point out that this is a problem that was solved automatically
by Multics and TOPS-20 (and could have been solved by VMS, but wasn't).
In Multics and TOPS-20 there are no read and write system calls.
Instead of doing "input/output", you just map a region of a disk file
to a region of memory; the memory management hardware and software do
all the rest. In fact, Multics took it a step further by eliminating,
from the application's point of view, any distinction at all between
files and memory regions. But since I'm much more familiar with
TOPS-20, I'll describe their technique and leave the Multics stuff for
someone else...
In TOPS-20, by default all disk pages are mapped shareably with "copy-on-
write" set. This means that all pages, even writeable data pages, are
initially shared. The hardware bits are set to prevent writes. If a process
attempts to write into a copy-on-write page, a page fault occurs, the OS
makes a private copy of the page which is mapped in place of the shared
copy, and the process is resumed.
This solves the problem of sharing P-code. EVERYTHING is shared by default;
you have to ask specifically for private disk pages.
Now, you can't really kludge this into UNIX because UNIX programmers expect
to do I/O rather than page mapping. The semantics are all different (for
example, memory must be mapped on hardware page boundaries and in page sizes
fixed by hardware). So you end up not sharing data pages, or adding special
kludge system calls in order to share them.
Oh well, just a little nostalgia for a really nice but now commercially dead
operating system...
--
Larry Campbell The Boston Software Works, Inc.
Internet: campbell@maynard.BSW.COM 120 Fulton Street, Boston MA 02109
uucp: {husc6,mirror,think}!maynard!campbell +1 617 367 6846
Technical Details
Message-ID:
<984@mcdchg.UUCP>Path:
arc1-ca.pugleaf.net!utzoo!mnetor!seismo!husc6!hao!gatech!mcdchg!usenetReferences:
<881@mcdchg.UUCP>Show Full Headers
Complete Article Headers
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: arc1-ca.pugleaf.net!utzoo!mnetor!seismo!husc6!hao!gatech!mcdchg!usenet From: campbell@maynard.BSW.COM (Larry Campbell) Newsgroups: comp.unix Subject: Re: UNIX Facilities for Interpreters Message-ID: <984@mcdchg.UUCP> Date: Mon, 29-Jun-87 20:58:41 EDT Article-I.D.: mcdchg.984 Posted: Mon Jun 29 20:58:41 1987 Date-Received: Sat, 4-Jul-87 18:47:38 EDT References: <881@mcdchg.UUCP> Sender: usenet@mcdchg.UUCP Organization: The Boston Software Works, Inc. Lines: 44 Keywords: UNIX Multics TOPS-20 memory mapping Approved: usenet@mcdchg.UUCP Summary: wanted: REAL memory management