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) |
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 */
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.