|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 firstname.lastname@example.org (1987-12-09)|
|Re: Compilers producing assembly language email@example.com.COM (1987-12-10)|
|Re: Compilers producing assembly language firstname.lastname@example.org (1987-12-14)|
|Date:||2 Dec 87 16:23:00 GMT|
|Posted:||Wed Dec 2 17:23:00 1987|
|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
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?
Microprocessor Tools Group
Nixdorf Computer AG, Paderborn, Germany
(personal communication, of course)
S-mail: Rainer Glaschick
Nixdorf Computer AG
[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]
Return to the
Search the comp.compilers archives again.