Re: Why do we still assemble?

Kendall Bennett writes
> Actually, once again in the PC world the Watcom C/C++ compiler (this
> compiler is actually very slow at loading itself compared to most, but it
> produces the _fastest_ code on the PC - faster in fact than gcc) comes
> with a small utility called WDISAM.EXE, which does exactly that. In fact
> it goes further since it can generate readable symbol table output, or you
> can get it to generate MASM'able or Unix'ish style assembler output.


The disassembler used with the latest version of xlc supports the -S
switch and produces more or less readable ouput that is valid input for
the assembler. (The program that does this lives in /usr/lpp/xlc/bin/dis
if its not installed somewhere more convenient.) The xlc compiler will
also generate listing (.lst) files if given the -qlist switch. These are
not exactly human readable, but if you spend enough time looking at them
your neurons rewire and they start to make sense :-)


I still end up using gcc for certain things for the ability to write
inline assembly. This is an incredibly valuable tool and should not be
left out of the compiler, even if you don't emit assembly. (Which implies
that you may have to wire an assembler into the compiler.) I'd also like
to see more tools which support the idea that producing assembly is a
cooperative process involving the programmer. A process involving
translation steps where the programmer can provide more information and
guide the decisions the tools must make. The goal here is not so much to
make writing the code faster than writing hand optimized assembly, but to
improve correctness and portability. To be useful, the added hints
probably have to eventually be fed back so they come in with the
high-level source code.
--
Zalman Stern zalman@adobe.com (415) 962 3824
Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900
--

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