Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!necntc!ima!johnl
From: gla@nixpbe.UUCP
Newsgroups: comp.compilers
Subject: Re: Compilers producing assembly language
Message-ID: <26100001@nixpbe.UUCP>
Date: Wed, 2-Dec-87 11:23:00 EST
Article-I.D.: nixpbe.26100001
Posted: Wed Dec  2 11:23:00 1987
Date-Received: Sun, 13-Dec-87 02:41:14 EST
References: <765@ima.UUCP>
Sender: johnl@ima.ISC.COM
Reply-To: gla@nixpbe.UUCP
Lines: 59
Approved: compilers@ima.UUCP
Nf-ID: #R:ima:-76500:nixpbe:26100001:000:1868
Nf-From: nixpbe!gla    Dec  2 17:23:00 1987

Well, there are a lot of generic UNIX compilers that generate object
code directly. For example, the Pyramid 90x family idem Nixdorf Targon/35
and soon the whole Nixdorf Targon Family.
There is good reason to do so.

First, it is a performance reason.
Lexical analysis takes about 30% of time in any compile/assembly
program. This can be saved if the assembly step is integrated.

Next, a lot of assemblers have reserved words. These will then
either be forbidden in the source languages, or the compiler
will prefix each name with something, e.g. an underscore.
Other curious restrictions might make extra effort to the
code generator. An INTEL 8086 assembler e.g. treats an EXTERN
inside or outside a segment/procedure different.

Third, and most important, you cannot pass correct debugging information,
e.g. source line numbers and symbol attributes.

Fourth, the assembler is far too powerful. It will keep all labels
ever generated and seldom will have an option to forget local
symbols, etc.

On the other hand, there is also good reason to use Assembler source
and the normal assembler.

First, maintenance is far more easy if you can edit the code output.

Second, you must have such a beast anyhow, why duplicate the effort?

Third, you have an assembly listing that is not an approximation
but the true listing. Especially important for real-time software
or device controllers.

Any more questions?

Rainer Glaschick
Microprocessor Tools Group
Nixdorf Computer AG, Paderborn, Germany
(personal communication, of course)

UUCP:   {seismo,mcvax}!unido!nixpbe!glaschick
NERV:   glaschick.pad

Phone:  nat-5251-14-6153
FAX:    nat-5251-14-6108

S-mail: Rainer Glaschick
	Nixdorf Computer AG
	Entwicklungstechnik
	Pontanusstr. 55
	D-4790 Paderborn
	W-Germany
[Some of the objections to assembler are not always valid, e.g. most Unix
assemblers pass through lots of debugging symbols and have local symbols.
On the other hand, it took me a while to figure out why I was having such
trouble on an 8086 with a symbol called AL.  -John]
--
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