Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!ames!cit-vax!usc-oberon!castor.usc.edu!blarson
From: blarson@castor.usc.edu.UUCP
Newsgroups: comp.arch,comp.lang.c
Subject: Re: String Handling and run-time libraries
Message-ID: <1417@castor.usc.edu>
Date: Thu, 2-Apr-87 02:28:17 EST
Article-I.D.: castor.1417
Posted: Thu Apr  2 02:28:17 1987
Date-Received: Sat, 4-Apr-87 12:40:30 EST
References: <15292@amdcad.UUCP> <978@ames.UUCP> <15694@sun.uucp> <6042@mimsy.UUCP> <287@pembina.alberta.UUCP>
Reply-To: blarson@castor.usc.edu.UUCP (Bob Larson)
Organization: USC AIS, Los Angeles
Lines: 21
Xref: utgpu comp.arch:753 comp.lang.c:1439

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
>images from one type of Vax to another and your program will
>run with the most efficient `str*' routines available for that
>machine, ie.  the routines in that machines resident library.

This isn't the only, or nessisarily best, way to implement shared
libraries.  Primos implements shared libraries via faulted links.
(call by name first time a routine is called, which replaces the
faulting pointer with one the actual routine.)  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. (Hmmm... does a user process
ever need to reference the kernal area of memory?))  Of course, VMS
uses entry vectors, and we all know VMS does everything right. :-)
-- 
Bob Larson
Arpa: Blarson@Usc-Eclb.Arpa
Uucp: (several backbone sites)!sdcrdcf!usc-oberon!castor.usc.edu!blarson
			seismo!cit-vax!usc-oberon!castor.usc.edu!blarson