Re: Compilers producing assembly language

2 Dec 87 16:23:00 GMT

          From comp.compilers

Related articles
Compilers producing assembly language uiucdcs!gatech!emory!arnold (1987-11-24)
Re: Compilers producing assembly language harvard!drilex!dricej (1987-11-29)
Re: Compilers producing assembly language allegra!utzoo!henry (1987-12-03)
Re: Compilers producing assembly language gla@nixpbe.UUCP (1987-12-02)
Re: Compilers producing assembly language haddock!csun!aeusesef (1987-12-06)
Re: Compilers producing assembly language (1987-12-09)
Re: Compilers producing assembly language rcd@ico.isc.COM (1987-12-10)
Re: Compilers producing assembly language (1987-12-14)
| List of all articles for this month |

From: gla@nixpbe.UUCP
Newsgroups: comp.compilers
Date: 2 Dec 87 16:23:00 GMT
Article-I.D.: nixpbe.26100001
Posted: Wed Dec 2 17:23:00 1987
References: <765@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
Pontanusstr. 55
D-4790 Paderborn
[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]

Post a followup to this message

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