Re: MS-COFF Object Files

albaugh@agames.com (Mike Albaugh)
19 Nov 1996 00:22:10 -0500

          From comp.compilers

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)
| List of all articles for this month |

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
--


Post a followup to this message

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