Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!mit-eddie!uw-beaver!ubc-vision!alberta!bjorn
From: bjorn@alberta.UUCP
Newsgroups: comp.arch,comp.lang.c
Subject: Re: String Handling and run-time libraries
Message-ID: <294@pembina.alberta.UUCP>
Date: Sun, 5-Apr-87 19:00:17 EST
Article-I.D.: pembina.294
Posted: Sun Apr  5 19:00:17 1987
Date-Received: Thu, 9-Apr-87 03:08:33 EST
References: <15292@amdcad.UUCP> <978@ames.UUCP> <15694@sun.uucp> <6042@mimsy.UUCP> <1417@castor.usc.edu>
Organization: U. of Alberta, Edmonton, AB
Lines: 50
Xref: utgpu comp.arch:796 comp.lang.c:1494
Summary: Still on shared resident libraries

In article <1417@castor.usc.edu>, blarson@castor.usc.edu (Bob Larson) writes:
>In article <287@pembina.alberta.UUCP> bjorn@alberta.UUCP (Bjorn R. Bjornsson) writes:
>>Assuming a
>>vectored entry point interface to the library, you can move your
>This isn't the only, or nessisarily best, way to implement shared
>libraries.  Primos implements shared libraries via faulted links.

Note that I did not specify where the entry vector was to be located.
It can be in the library or in your process.  Having the vector in
your process rather than the library may give you little bit more
flexibility at the cost of space, perhaps a significant amount
(depending on the library size and or the number of routines you need).

>(call by name first time a routine is called, which replaces the
>faulting pointer with one the actual routine.)

I was aware of this method and you can use it in conjunction with
the entry point vector scheme.  You initialize the vector with
distinct values that are guaranteed to cause an access violation.

>  I think this is yet
>another idea they borrowed from Multics.  (The hardware overhead is a
>fault bit on pointers, but you could implement it on a vax by
>reserving half of your address space.

As I alluded to above all that is needed is that such pointers
are guaranteed to fault and that they be distinguishable from each
other.  There is no requirement to reserve half the address space.

I'm getting a little rusty in some of the small details of VMS but
if memory still serves me the VMS run time library lives in system
space (this makes a lot of sense by the way).

> (Hmmm... does a user process
>ever need to reference the kernal area of memory?))

Certainly there have been a lot of lot of service programs written
by non-DEC folks that execute partially in kernel mode to obtain
whatever info they need from VMS.  This is not for the faint of
heart though and you do need CMKRNL (change mode to kernel) privileges.
Now whether you call such programs "user programs" or not is entirely
up to you.

>  Of course, VMS
>uses entry vectors, and we all know VMS does everything right. :-)

It costs enough so it had better do everything right B-).

			Bjorn R. Bjornsson
			alberta!bjorn