Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site dartvax.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!harvard!talcott!panda!genrad!decvax!dartvax!chuck
From: chuck@dartvax.UUCP (Chuck Simmons)
Newsgroups: net.arch,net.unix-wizards
Subject: Re: Shared runtime libraries - SV shared memory?
Message-ID: <3075@dartvax.UUCP>
Date: Thu, 16-May-85 03:20:50 EDT
Article-I.D.: dartvax.3075
Posted: Thu May 16 03:20:50 1985
Date-Received: Fri, 17-May-85 04:10:37 EDT
References: <388@rtech.ARPA>
Distribution: net
Organization: Dartmouth College, Hanover, NH
Lines: 37
Xref: linus net.arch:1013 net.unix-wizards:10399

>   In a random discussion with a co-worker the other day, I recalled a
> scheme for reducing the size text segments of programs used in an
> otherwise excreble and unnamed operating system:  Shared runtime
> libraries.  Though I have no current application, it seemed like an
> interesting topic to bounce around.

Here at Dartmouth, we are slowly working on bringing our operating system
into the 80's.  Recently, two programmers around here rewrote the
operating system to take advantage of the virtual mode hardware.  Presently
a few people are rewriting various compilers, the linker, the loader, and
the common runtime routines.  When (if) we are through, all the common
runtime routines will be kept in a canonical location and will be sharable
by all user programs.

This is implemented as follows:  First off, we have a table that tells
where every defined object is within the common runtime library.  Each
compiler (pl1, pascal, basic, and maybe someday fortran and cobol) will
know the offset within this table of each defined item.  Each table entry
contains a pointer to the actual location of the defined item.  This extra
level of indirection makes this scheme slightly less gross than it otherwise
would be.  

Secondly, when a
user program starts up, it opens up the library routines as a memory
segment.  The operating system handles the problems of allowing users
to share this file in some magic manner.  Thirdly, each user program requests
another memory segment from the operating system.  This other memory segment
is used to store impure data and impure code for the common runtime routines.
The common runtime routines know that the nth memory segment was created
for them.

Now I wonder...  was anyone interested in that?  Hopefully Gelhar
will correct any blatant errors in my description...

-- Chuck Simmons