Path: utzoo!utgpu!water!watmath!dvlmarv!alanm
From: alanm@dvlmarv.UUCP (Alan Matsuoka)
Newsgroups: comp.software-eng
Subject: Re: Question Re: Configuration Management
Message-ID: <1069@dvlmarv.UUCP>
Date: 24 Feb 88 22:34:46 GMT
References: <497@aimt.UUCP> <5257@well.UUCP> <2984@metavax.UUCP> <679@cresswell.quintus.UUCP>
Reply-To: alanm@dvlmarv.UUCP (Alan Matsuoka)
Organization: Develcon Electronics, Toronto
Lines: 56

In article <679@cresswell.quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes:
>In article <2984@metavax.UUCP>, chris@metavax.UUCP ( PSA) writes:
>
>Now, why can't you do this with a single file such as what
>	cc -c ugh.c
>gives you?  Not because the linker is stupid, but because it is in
>general impossible.  Suppose you have
>
>	cat <<EOF >foo.c
>	static f(...){...}
>	static g(...){...}
>	h(...){... f() ...}
>	i(...){... g() ...}
>	EOF
>
>If you use h(), you'd like just h() and f(), right?  But how is the
>linker supposed to know that h() uses f()?  The compiler has to tell
>it, and UNIX compilers don't do that.  

Yes, but only when the loader text  is defined in the UNIX tradition.
The problem here is the fact that all symbols and their references
are defined relative to a single compilation unit. If the loader text
contained directives ( like many other systems ) that would allow
you to define seprarately named sections, then it isn't too
hard to write a linker that can  accomplish the same thing as having
separate files. The problem is really one of granularity.

I suppose that it wouldn't too hard to then build the static calling
graph of the code ( why not ? Gprof can do it ), sort the addresses
and rearrange the code during the final writing phase to
allow for better locality.

The other issue is that in the context of UNIX systems a lot
of people don't really care if there is some dead code loaded or not.
In the case of a heavily loaded system on a small machine, I WOULD
care but in view of the fact that horsepower is getting cheaper and
memory even more so it becomes less of an issue.

On the other hand, I can remember somebody else pointing out that
if you can improve the execution time of a program running on something
like a heavily loaded 3090 by 1% , then you free up enough MIPS to
equal 100 PC's ( or something like that).

> In fact, there's no law that
>says a smart compiler can't notice that h() and i() look pretty similar
>and decide to share some code between them.  Indeed, in the special
>case of string literals, there are lots of C compilers that DO this.

And in some cases code as well. As I can recall, some experimental
code space optimizers can look at the entire Hierarchical directed
graph of a compilation unit, find the common subgraphs, create
the appropriate functions and procedures and their calls
and build a program that runs in a smaller code space.
Sorry, I don't know of any existing C compilers that will do this.
The one that I saw was written at a university for Pascal and it was nowhere
near to becoming a production compiler.