Related articles |
---|
[6 earlier articles] |
Re: Linker ... still useful ? ram+@cs.cmu.edu (Rob MacLachlan) (1994-09-27) |
Re: Linker ... still useful ? steve@cegelecproj.co.uk (1994-09-28) |
Re: Linker ... still useful ? jan@neuroinformatik.ruhr-uni-bochum.de (1994-09-28) |
Linker ... still useful ? Roger@natron.demon.co.uk (1994-09-28) |
Re: Linker ... still useful ? gnb@bby.com.au (1994-09-29) |
Re: Linker ... still useful ? andrew@cee.hw.ac.uk (1994-09-30) |
Re: Linker ... still useful ? marks@orb.mincom.oz.au (1994-10-05) |
Re: Linker ... still useful ? ok@cs.rmit.oz.au (1994-10-06) |
Re: Linker ... still useful ? monnier@di.epfl.ch (1994-10-07) |
Re: Linker ... still useful ? baynes@ukpsshp1.serigate.philips.nl (1994-10-10) |
Re: Linker ... still useful ? dmason@uwaterloo.ca (1994-10-15) |
Newsgroups: | comp.compilers |
From: | marks@orb.mincom.oz.au (Mark Stavar) |
Keywords: | linker |
Organization: | Mincom Pty. Ltd. |
References: | 94-09-179 |
Date: | Wed, 5 Oct 1994 05:07:13 GMT |
Gregory Bond (gnb@bby.com.au) wrote:
: Sure, 70's technology linkers are old, but they have one major advantage:
: doing a simple job, they can be quick. The more work the linker has to
: do, the slower it gets. And linking is the the one part of the program
: building process that has a serial bottleneck. The more work that we can
: push into the "compiler", the better we are able to use multiprocessors
: (simply by using a parallel make, if nothing else).
: Linking is already enough of a bottleneck that there apparently is a
: market for third-party high-speed incremental linkers (e.g. Purelink).
: Any serious work on "ld-The Next Generation" is going to have to have
: parallelisation as a high priority. And given the global nature of the
: job, I'm not sure there is huge scope.
I continue to be surprised each time we strike a linker that requires us
to specify a library name more than once on the command-line in order to
ensure resolution of symbol references.
Another area is one of hard limits, for numbers of symbols, etc. This has
bitten us several times when combining objects that derive from C code, C
code generated by Oracle's Pro*C embedded SQL precompiler, and MicroFocus
Cobol (ugly isn't it !-P). By the time all of this reaches the link
phase, we are exceeding the 64K limit on numbers of global symbols allowed
in objects. Oracle is the major offender here, with something like 3
global symbols generated for every host variable (including indicator
variables).
<stepping onto highest available soap box ...>
In this day of high performance machines and cheap disk/memory, why impose
hard limits, even very large ones. This is certainly a throw-back to the
above mentioned 70's technology. Fixed table sizes, linear searches,
etc., are a thing of the past. For too long we have had to endure silly
limitation, hacking together work-arounds, fighting....
<stepping off soap box, somewhat embarrassed...>
Ahem. Sorry about that. Think you get the drift of what I think would be
nice enhancements.
Ciao,
marks
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.