Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!bellcore!uunet!munnari.oz.au!brolga!bunyip.cc.uq.oz.au!qut.edu.au!lunnon
From: lunnon@qut.edu.au
Newsgroups: comp.sys.atari.st
Subject: Re: What's the BEST CLI for the ST
Message-ID: <1991Mar18.100958.25519@qut.edu.au>
Date: 18 Mar 91 15:09:57 GMT
References: <170@gem.stack.urc.tue.nl> <7340098@hpfcso.FC.HP.COM>
Organization: Queensland University of Technology
Lines: 99

In article <7340098@hpfcso.FC.HP.COM>, mjs@hpfcso.FC.HP.COM (Marc Sabatella) writes:
>>This would be nice but why doesn't someone take a standard ansi C library
>>and make a shareable version taht can be loaded at boot time and there
>>after used ( Via a trap for example ) then with the appropriate binding
>>the text size of executable could be reduced by the size of the linked
>>library. How about a coff loader for TOS and dynamic linking :-)
> 
> This could actually be done fairly easily; the main issue is what to do with
> program references to library data.  You would have to either change all the
> compilers to make such references indirectly, or make the linker smart enough
> to copy the data (like errno) into your program, and have the runtime system
> smart enough so that the shared C library can reference data in your program.
> The latter is nontrivial.

This is true but with limitations this could be simplified. Really when we
deal with libraries they are pretty much black boxes, what we get depends
on the implementation. Errno is really the only real problem point in the
whole C library and ANSI defines it as an Lvalue Macro so any implementation
which lets you write errno=87 will be ok. So if the library contains no
reference to _errno then the global reference to the volatile name in the
programs space will be used by the library. The real problem then is having
the library know which errno to use at any time. This would have to be to be
context sensitive.

for example when a new process is started a pointer to a
process link table be generated with all this type of data.
This variable is kept in the process table in the OS and installed as
the current application binding at each context switch or at each p_exec
eg

typedef struct process_static_table {

		int * errno;
		struct fileblock fb;
		int etc
		char **environment
			...
			...
		} ptable;

ptable c_library;
context_pt=&c_library;
 

For user generated libraries, such static references are banned

the errno Macro then in the library may be 
*(context_pt->errno)

alternatively we can have 
*(get_errno_ptr())
where get_errno_ptr() is a function in the current programs space not the
library.

ie

int *get_errno_ptr()


ANSI cleared up a lot of this junk


> 
> Also note that the libraries needn't be loaded at boot time; the startup code
> for the program could load libraries as appropriate, thus allowing arbitrary
> libraries to be shared on demand.

True, but it _IS_ easier to load them at boot time :-)


> 
> As for static data in shared libraries, that is usually implemented in Unix
> implementations by the same "copy-on-write" mechanism used by fork() for
> program data segments.

I am told this is difficult with no MMU


PS. Since I am talking off the top of my head, and because I am an engineer
not a computer scientist, what I have said probably does not make the slightest
sense and probably will not work. It is here merely to provoke thought.
(No waranties whether implied or otherwise :-)

(QUT does not pay me to write ramblings like this so don't blame them either )

	BOB
	R.Lunnon@qut.edu.au

PPS- Don't expect me to write this, I haven't even got around to re-developing
a 2 ic interlace mod for posting yet, if you expect this, well ...  Ha Ha Ha ...
Ha Ha Ha Ha Ha Ha Ha Ha (recursion starts here)


> 
> --------------
> Marc Sabatella (marc@hpmonk.fc.hp.com)
> Disclaimers:
> 	2 + 2 = 3, for suitably small values of 2
> 	Bill and Dave may not always agree with me