Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ihnp4!ptsfa!ames!ucbcad!ucbvax!decvax!decwrl!sqm.dec.com!jmsynge
From: jmsynge@sqm.dec.com.UUCP
Newsgroups: comp.sys.amiga
Subject: Re: Run-time named library vectors... suggestion for 1.3
Message-ID: <10273@decwrl.DEC.COM>
Date: Sun, 7-Jun-87 15:30:56 EDT
Article-I.D.: decwrl.10273
Posted: Sun Jun  7 15:30:56 1987
Date-Received: Mon, 8-Jun-87 05:40:46 EDT
Sender: daemon@decwrl.DEC.COM
Organization: Digital Equipment Corporation
Lines: 57

I'm glad Matt brought this idea up.  I've been contemplating how this could be
built into the Amiga.  The one system which I've used that had this form of
linkage (Prime's PRIMOS Operating System, apparently based on Multics) was
really great to use.  The references were resolved the first time they were
used, not at image activation.

One difficulty with the scheme Matt mentioned: How does the library function
know where it's Library structure is?  Currently, the non-shared libraries 
(c.lib for Aztec users) contain glue routines which place this value in A6.

A suggestion: the new hunk type could define a table of 6 byte entries.

	struct DynamicLinkage {
		struct Library	* dl_Library;
		short int	  dl_LVO;	/* Library Vector Offset */
	}

dl_LVO would be a signed offset (always negative) which is the offset into the
library vector.  This table could be constructed at run time by the loader.

This table would be used by the glue routines which would still need to be
provided, but the values would be resolved automatically.  (Question: how
would the library be closed?  Currently this must be done explicitly.)

Now you could have two types of run-time library references: those which
specify the name of a function (i.e. printf) and those which specify a library
name (exec.library).  The latter could have the offset value prespecified.
This distinction could could be made during linkage.

A change would be also be needed to all the shared libraries:  The would need
a way to tell loader which routines they contained.  Perhaps one of the flag
bits (lib_Flags) in the Library structure could indicate that there was an
additional pointer at the end of the structure (lib_FunctionNames ?) which 
pointed to a list of 6 byte entries. 

	struct LibraryFunctionEntry {
		char *		lfe_Name;
		short int	lfe_LVO;
	}

Alternately, the library's initialization code could call a new exec function
in order to declare the names of the library's functions.

For efficiency it would probably be necessary for the loader to hash the
names so that image activation wouldn't be unbearably slow.

Those who have read this far will have gotten the idea that I think this is
a GREAT thing to do.  It is!  If you would like further info about some real
systems which use this, feel free send me email.

James Synge

USENET:  {decvax, ucbvax, allegra}!decwrl!sqm.dec.com!jmsynge
ARPAnet: jmsynge%sqm.DEC@decwrl.DEC.COM

#include <disclaimer.h>
"Ken Olsen can speak for Digital, not me!"