Related articles |
---|
MS-COFF Object Files gleeh@tulletts.sprint.com (1996-11-10) |
Re: MS-COFF Object Files meissner@cygnus.com (Michael Meissner) (1996-11-12) |
Re: MS-COFF Object Files htak@eskimo.com (1996-11-12) |
Re: MS-COFF Object Files shankar@chromatic.com (1996-11-12) |
Re: MS-COFF Object Files alt-x@erinet.com (1996-11-14) |
Re: MS-COFF Object Files albaugh@agames.com (1996-11-19) |
From: | albaugh@agames.com (Mike Albaugh) |
Newsgroups: | comp.compilers |
Date: | 19 Nov 1996 00:22:10 -0500 |
Organization: | Atari Games Corporation |
References: | 96-11-071 96-11-082 |
Keywords: | linker |
I'm actually responding to the quoted text, which I missed
during a news-outage here...
Hugo <gleeh@tulletts.sprint.com> wrote:
>When you think about it, the obj format is nothing to do with code
>generation, I wonder if anyone has any views or info on this aspect
>of compilers ?
This is not really true. It may _appear_ true to folks who
have only ever seen a.out, or one of the "a.out with tailfins" object
formats so popular today, but trust me, converting tools from a
"stream-based" linker such as Fraser And Hansen's Machine Independant
Linker", complete with arbitrary expressions, link-time conditiopnals,
etc..., to a.out or its cousins is _no_ picnic. As I recall, there
were pieces in the gcc aux-output.c for the Moto 68K series that had
to do with some assemblers (that is, some object file formats) being
unable to assemble PC-relative references to tables that had not yet
been emitted. There are probably programs running as we speak that
are taking extra unconditional branches around the jump-tables of
switch statements _just_ to accomodate such silliness. I vaguely
recall similar inability to use 8-bit displacements in some x86 code a
friend was porting.
Henry S. Takeuchi (htak@eskimo.com) wrote:
: The output routines know nothing about CPU instructions, only about
: what kinds of relocatable data are possible.
With a stream-based linker, just about _any_ kind of
relocatable data are possible. Unfortunately, taking advantage of such
in a world where a.out-with-tailfins has taken over is a severe CLM
:-)
BTW: before anybody re-issues the old rejoinder that stream-
based linkers are slow, I'd like to reply-in-advance that a "make" of
a significant embedded project (approx 40 object files) actually ran
_faster_, on the same machine, using a home-brewed macro-assembler and
linker (pre-existing, for "industrial strength" embedded assembly
work, hence a superset of what you get with gas/gld) than gas/gld.
No, I no longer have the system in question, but also, no, I didn't
run gas/gld first to "warm-up" the disk-cache. I'll also admit that
the time difference was down in the noise, but it was clearly not a
"huge win" for a.out, as the person who challenged me to run the test
alleged it would be. It was a "small loss".
Mike
| Mike Albaugh (albaugh@agames.com) Atari Games (now owned by Williams)
| (No connection to Warner or any company owned by the Tramiel family)
| 675 Sycamore Dr. Milpitas, CA 95035 voice: (408)434-1709
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.