Re: Why do we still assemble?

lgc@robotics.jpl.nasa.gov (Loring Craymer) writes:
>My experience has been that if you are doing systems-level programming on
>a platform that is either experimental or poorly supported, then an
>assembler intermediate--which can be run through a filter--can be a
>necessity. This makes it possible to:
>
> 1.) Gain access to processor-specific features not
> considered essential by the compiler writer...
>
> 2.) Work around bad code generation.


When I first started reading this thread, I wanted to say a few things.
Now (with the proper introduction) I will.


Point #2 above is an important one. Also note that the definition of `bad
code' will vary depending upon who you are talking to, and what they are
doing at the moment. I have consulting clients who are doing embedded
systems programming, and for them, `bad code' is not just code which gives
outright incorrect answers... It is also code which runs too slowly.


Now consider how an end-user would know where or how `bad code' (e.g. slow
code) is being generated. Sure, one sees the effects (i.e. slow running
programs) but that alone isn't always sufficiently helpful in tracking
down the problem.


Programmers dealing with real-time systems (or other kinds of systems
where performance is critical) may often wish to inspect the assembly code
them- selves, just to see where all of the time is going, and to see what
coding idioms they should favor, and which ones to avoid (both of which
are highly compiler dependent). One *could* look at machine code to learn
about these things, but I believe that almost everyone would agree that
the assembly code level is far more appropriate for this kind of
inspection.


So at the very least, it can be helpful to get an assembly-code listing
from one's compiler.


Some folks have noted (in this thread) that there are compilers which
compile directly to object code, but which are provided with
disassemblers. That solution may be adequate (in some cases) but I (for
one) would worry that there would be a loss of significant (and useful)
information some- where in this sort of approach.


Another important category of people who might find it VERY useful to look
at the assembly code are the implementors themselves... and I think this
is a very important point which seems to have been missed in this whole
discussion so far. Let's face it. Compilers are not born fully formed or
fully debugged. Rather, most of them spend a great deal of their lives
being fixed in one way or another. (Believe me, I know. Check my
signature line.) Whenever the fixing process involves the generated code,
it's awfully helpful to be able to SEE that code at the assembly level.
In fact, one useful technique that I think an awful lot of implementors
have missed out on is the addition of a compiler option which will trigger
the compiler NOT ONLY to produce assembly code, but also detailed comments
embedded therein, which help to explain what the compiler did (with
respect to code generation) and why it did it.


(An example of this technique may be seen by configuring the GNU C
compiler for some target system where DWARF format symbolic debugging
information is used, and then invoking it with the -fverbose-asm option
together with the -S option. In the generated assembly file, comments
provide additional information which render the DWARF info readable by
normal humans... not just by assemblers.) --


-- Ron Guilmette, Sunnyvale, CA ---------- RG Consulting -------------------
---- domain addr: rfg@netcom.com ----------- Purveyors of Compiler Test ----
---- uucp addr: ...!uunet!netcom!rfg ------- Suites and Bullet-Proof Shoes -
--

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