Re: Are Better Linkers Possible?

Martin Leiser <leiser@ibiza.karlsruhe.gmd.de>
Thu, 22 Aug 91 14:02:28 +0200

          From comp.compilers

Related articles
Are Better Linkers Possible? westfal@mprgate.mpr.ca (1991-08-20)
Re: Are Better Linkers Possible? pardo@gar.cs.washington.edu (1991-08-21)
Re: Are Better Linkers Possible? leiser@ibiza.karlsruhe.gmd.de (Martin Leiser) (1991-08-22)
Re: Are Better Linkers Possible? bgb@iexist.att.com (1991-08-24)
| List of all articles for this month |
Newsgroups: comp.compilers
From: Martin Leiser <leiser@ibiza.karlsruhe.gmd.de>
Keywords: linker
Organization: Compilers Central
Date: Thu, 22 Aug 91 14:02:28 +0200

To find a criterion for what should and should not be in the linker, one
should recognize, that link time is the bottle neck in the compile-edit-link
cycle (see the excellent article of Quong and Linton in acm Transactions Vol
13, 1 January 1991 p. 1 Linking Programs Incrementally, how to solve this
problem).


So the linker should do only things, which require global knowledge of the
program (such as linking, or inline inclusion), based on data structures
containing preprocessed information to decide e.g. about inline inclusion.
The algorithms in the linker must be linear, and should fit in the typical
two pass linker implementation.


Object orientation is a compile time animal. Only initialization and
termination chaining is the only new thing, which can (with minimal run time
penalty) also be solved at run time.


Configuration management (versioning and so on) can not be done in a linker,
it is possible to decide about that beforehand. It's the CM systems task to
decide what to link, and it should be as simple to tell a linker about how to
retrieve the stuff from an whatever looking database system, as it is to pass
the linker a set of file names.


Martin Leiser leiser@ibiza.karlsruhe.gmd.de
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.