|MS-COFF Object Files firstname.lastname@example.org (1996-11-10)|
|Re: MS-COFF Object Files email@example.com (Michael Meissner) (1996-11-12)|
|Re: MS-COFF Object Files firstname.lastname@example.org (1996-11-12)|
|Re: MS-COFF Object Files email@example.com (1996-11-12)|
|Re: MS-COFF Object Files firstname.lastname@example.org (1996-11-14)|
|Re: MS-COFF Object Files email@example.com (1996-11-19)|
|From:||firstname.lastname@example.org (Mike Albaugh)|
|Date:||19 Nov 1996 00:22:10 -0500|
|Organization:||Atari Games Corporation|
I'm actually responding to the quoted text, which I missed
during a news-outage here...
Hugo <email@example.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 (firstname.lastname@example.org) 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 Albaugh (email@example.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
Search the comp.compilers archives again.