|Are Better Linkers Possible? firstname.lastname@example.org (1991-08-20)|
|Re: Are Better Linkers Possible? email@example.com (1991-08-21)|
|Re: Are Better Linkers Possible? firstname.lastname@example.org (Martin Leiser) (1991-08-22)|
|Re: Are Better Linkers Possible? email@example.com (1991-08-24)|
|From:||Martin Leiser <firstname.lastname@example.org>|
|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
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 email@example.com
Return to the
Search the comp.compilers archives again.