Submission for comp-compilers

From: Hank_Gupton@stjhmc.uucp (Hank Gupton)
Newsgroups: comp.compilers
Subject: From UseNet
Message-ID: <999.21CF315F@stjhmc.uucp>
Date: 22 Dec 87 22:58:16 GMT
Organization: FidoNet node 114/15 - St Joes Hospi, Phoenix AZ
Lines: 183


I grabbed this from a local BBS offering UseNet. I wish there was more going
on in the Fido News Group by the same name. The news group is
"comp.compilers".




  - - - - - - - - - - - - - - - - - - - - - - - - - - - -




Article 13 of 44, Dec 8 12:07.
Subject: Compiler Output
Keywords: compilers, assemblers, languages
From: gm@amdahl.amdahl.com (G. M. Harding @ Amdahl Corporation, Sunnyvale CA)


          Rainer Glaschick of Nixdorf Computer AG offers a good
summary of the issues involved in deciding on a compiler's
output format (assembly source vs. relocatable object). As the
Manager of UTS Languages (UTS is our Unix port) at Amdahl
Corp., I'm mulling over such issues right now. (No, I'm not
announcing any new products, and wouldn't even if I had any,
and furthermore am not trying to imply that I either do or
don't have any, but realistically, compilers have to evolve
just like other programs, and it pays to plan ahead.)


          My personal bias (for this is a highly subjective and
emotion-laden area) favors the generation of assembler source
code. For one thing, that is standard Unix practice. For
another thing, as Rainer says, you have to offer the option
of generating source anyway, and it's redundancy on an immense
scale to incorporate assembler-like logic (and possibly even
disassembler-like logic) in the compiler's back end. After all,
the whole spirit of Unix is: One task, one program.


          But though I consider these reasons persuasive, I do not
consider them compelling. The real reasons for generating
assembler source are:


          (a) It's less confusing for the person who writes the
back end. Compilers have enough bugs as it is; it can only make
things worse if the engineer responsible for code generation
has to deal with an additional level of complexity. Besides,
from a development standpoint, separating the two types of
translation allows work on the compiler and the assembler to
proceed in parallel.


          (b) If you emit source, you can (and jolly well should)
design the compiler to read stdin and write stdout. Then, you
can actually run it as a stand-alone, interactive program.
Needless to say, this simplifies compiler debugging enormously.
For example, on UTS/580, you can type:


                              $ /lib/ccom
                              static int j = 17;
                              .data
                              ds 0f
                              j:
                              dc f'17'
                              .data
                                    .
                                    .
                                    .
                              ^D


          I agree that compile-time speed is an important design
consideration (though nowhere near as important as run-time
speed). Since the "cc" program invokes compiler and assembler
separately, it requires two separate text translation steps,
and thus is less than optimally efficient. But modern compu-
tational speeds are making this less and less of an issue,
especially (subtle plug) on Amdahl machines. Bear in mind, too,
that the C compiler is the most important software generation
tool on any Unix system, and a language like C compiles fairly
efficiently simply by virtue of its assembler-like constructs.
It's quite possible, given today's technology, to produce an
optimizing C compiler which will generate code almost as tight
as a skilled assembler programmer could write, and once you
have a good C compiler, you write all your other compilers
in C.


          Rainer is mistaken about one thing: You can, indeed, pass
debugging information from compiler to assembler. The assembler
must be prepared to accept this information (usually in the
form of special pseudo-ops), but it isn't terribly difficult
to modify the assembler accordingly.


          An 8086 compiler which gives the user grief over a symbol
named AL is an extremely poor compiler. It certainly isn't up
to Unix standards (which, according to one's religious convic-
tions, may or may not be saying much). The usual convention of
prepending an underbar to non-local symbols is straightforward
enough for me, and completely eliminates symbol clashes.


Foregoing opinions (C) 1987 by G. M. Harding; may not be
attributed, reattributed, rehashed, or repeated without an
express written disavowal of any meaningful content whatsoever.
--

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