Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!yetti!geac!daveb
From: daveb@geac.UUCP
Newsgroups: comp.lang.c
Subject: Re: near / far branches
Message-ID: <1640@geac.UUCP>
Date: Mon, 19-Oct-87 14:10:34 EDT
Article-I.D.: geac.1640
Posted: Mon Oct 19 14:10:34 1987
Date-Received: Mon, 19-Oct-87 23:31:23 EDT
References: <117@nusdhub.UUCP> <420@wrs.UUCP>
Reply-To: daveb@geac.UUCP (Dave Collier-Brown)
Organization: The little blue rock next to that twinkly star.
Lines: 32
Keywords: arizona linker


  A very reasonable (and reasoned) discussion between David
Goodenough and Robert C. White Jr., et all, prompts me to paraphrase
Christopher Fraser thusly:

  It is noticeable that assemblers do a lot of address resolution,
passing resolution on to a linker in cases where the information in
the assembler file is insufficient.
  The linker, in turn, does a lot of machine dependent loading.

  It is a good idea to teach the assembler to be just a single-pass
translator, passing all resolution off to the linker.  It is
admitted that this means identifying internal -vs- external symbols
to the linker so it does not mis-link an internal label "i" to an
external one or vice versa.
  It is now apparent that the linking algorithm is a merge-sort,
given a properly ordered set of linkable objects.  It is admitted
that this ordering may require a topological sort to properly order
the commands in the linkage control-file.
  It is finally apparent that the algorithm is portable to many (but
not all) machines, with the machine-dependent portion placed in a
separate loader.

  This is not to say that the classical form of linking is wrong,
merely that it is historical...

 --dave
-- 
 David Collier-Brown.                 {mnetor|yetti|utgpu}!geac!daveb
 Geac Computers International Inc.,   |  Computer Science loses its
 350 Steelcase Road,Markham, Ontario, |  memory (if not its mind)
 CANADA, L3R 1B3 (416) 475-0525 x3279 |  every 6 months.