Path: utzoo!mnetor!uunet!husc6!necntc!ima!johnl From: gm@amdahl.amdahl.com (G. M. Harding) Newsgroups: comp.compilers Subject: Compiler Output Message-ID: <777@ima.ISC.COM> Date: 8 Dec 87 19:07:37 GMT Sender: johnl@ima.ISC.COM Reply-To: gm@amdahl.amdahl.com (G. M. Harding) Organization: Amdahl Corporation, Sunnyvale CA Lines: 87 Keywords: compilers, assemblers, languages Approved: compilers@ima.UUCP 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. -- Send compilers articles to ima!compilers or, in a pinch, to Levine@YALE.ARPA Plausible paths are { ihnp4 | decvax | cbosgd | harvard | yale | cca}!ima Please send responses to the originator of the message -- I cannot forward mail accidentally sent back to compilers. Meta-mail to ima!compilers-request