Re: Why do we still link?

jhallen@world.std.com (Joseph H Allen)
Thu, 14 Apr 1994 21:47:53 GMT

          From comp.compilers

Related articles
Why do we still assemble? hbaker@netcom.com (1994-04-06)
Re: Why do we still link? c5cx016@boe00.minc.umd.edu (Ed Finch) (1994-04-13)
Re: Why do we still link? jhallen@world.std.com (1994-04-14)
| List of all articles for this month |
Newsgroups: comp.compilers
From: jhallen@world.std.com (Joseph H Allen)
Keywords: linker
Organization: The World Public Access UNIX, Brookline, MA
References: 94-04-032 94-04-083
Date: Thu, 14 Apr 1994 21:47:53 GMT

Thomas Conway wrote:
> What is the state of the art in linkers?


Ed Finch <c5cx016@boe00.minc.umd.edu> writes:
>In the DOS/Windows world, it's OPTLINK, by SLR Systems. ...


The biggest speed improvement achieved by OPTLINK (and others) over
Microsoft's linker is due to a ram-based library symbol table. '.LIB'
files have a hash table in them containing each symbol defined by the
modules making up the library. But if you actually use that hash table
through the file system, as does Microsoft's linker, it's incredibly slow.
Modern linkers simply make a pass over the libraries to build a symbol
table in RAM.


The rest of the performance gain is probably from some sort of incremental
linking.


So do any of these modern commercial linkers allow you to place segments
or groups explicitly? I.E., can you say that you want CODE followed by
DGROUP at segment 0x0000, VIDEO at 0xF000 and RESET at 0xFFFF? I had
posted a linked to do this to alt.sources a few years ago (called 'alink')
so that I could put Turbo-C code in ROM. I'm curious if any of the
commercial linkers let you do this yet.
--
/* jhallen@world.std.com (192.74.137.5) */ /* Joseph H. Allen */
--


Post a followup to this message

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