daveb@geac.UUCP (Dave Collier-Brown) (10/13/87)
In article <384@mcdsun.UUCP>, fnf@mcdsun.UUCP (Fred Fish) writes: || the linker fix up all the jumps that are really "near" jumps || to be "near" jumps. In either case, you either grow or || shrink the code as appropriate, in the linker. What could || be easier? In either case, you end up with exactly the same || executable object code. No nops, no "non-optimal" jumps, the || *same* *optimal* *code*. In article <117@nusdhub.UUCP> rwhite@nusdhub.UUCP (Robert C. White Jr.) writes: | First, a linker is a "linking loader" and it's only REAL |purpose is to resolve refrences and setup dynamic relocation |information [...] If it is so simple, I would love to see your compleeted |disassembling-assebeling-optomizing-editing-linking-loader on the |market. Gentlemen, such an assembler and linker exist, and the algorithms were published \begin{emphasis} a number of years ago \end{emphasis}. . From the published work I produced a CP/M version... which should imply just how old an idea it really is. You're having what is called a "verbal dispute", defined as two persons arguing with different definitions.... If you define a linker as a "linking loader", then by definition its a loader with fixups. If you strip the linking (fixup) code out of the assembler and let the linker do all the "linking", then you have the more modern version of a linker. (It is trivially true that the MS-DOS linker is just a linking loader. What that says about Microsoft is not pretty.) Look in an old copy of Software, Practice and Experience for Dave Hansen's "arizona linker". --dave (see below) c-b -- 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.