Re: Size of assembly programs...

Is it possible to discuss something in this news groups without someone
feeling the need to tell us that we should be sure to only optimize the
bottle necks?



robertwessel2@xxxxxxxxx wrote:
Steven Nichols wrote:
Compilers take the number of things into account that they they were
programmed for. Humans can take much more into account (in code design)
than the machine. The idea that a good optimizing compiler can do as
well as handwritten ASM is still a myth as far as I can tell at this
point. Compilers are getting better all the time.


I don't think there's any doubt that a good assembler programmer can,
given adequate time, outperform (or at least match) any compiler in
terms of code performance. Except perhaps in the minds of the
marketing departments of some compiler writers. ;-) That being said,
much of the complex instruction/register/functional unit/etc.
scheduling needed for many advanced CPUs is quite tedious and labor
intensive, and something that compilers can do reasonably well.

Unfortunately, (A) most assembler programmer's aren't that good, and
(B), those that are usually don't have near the time needed to dedicate
to the task except in relatively small portions of the application.
It's the old 90/10 rule: 90% of the CPU time is spent in 10% of the
code - any sane programmer will concentrate on making the 10% fast, and
getting the 90% done as quickly as possible while still being correct.
That often means that the 90%, when written in assembler, ends up being
fairly stylized and simplistic code, and not very optimized at all.
And *that* code will very, very often be beaten by a good compiler.
The 10% is another story, but even there it's quite common to start
with either simplistic code or an HLL implementation, so that things
*work*, and then optimize the bottlenecks (which are often surprising,
and don't make themselves obvious until you profile the code).

None of which is to say that there aren't clearly areas where compilers
get terribly lost. If the problem doesn't fit the HLL well, it's
unlikely that the resulting code will be very good. A good example is
a software implementation of DES (although even the best assembler
implementations of DES still suck - DES being designed to be
implemented in hardware, not software - but they're an order of
magnitude faster than say a good C version). Another example is the
double width integer multiplication available on many CPUs - if you're
doing a bignum library that's very handy, and totally inaccessible from
C.

.

Relevant Pages

  • Re: What micros do you actually hate to work with?
    ... with less than tiny asm ... hassle to work with 32 bit longs in assembler for an 8 bit uP, ... Microchip's C compiler tools and their assembly under MPLAB. ... is that other programmers for C are easier to find. ...
    (comp.arch.embedded)
  • Re: The Promise of Forth
    ... Declare variables, declare locals, let the compiler do the work ... Forth could be considered the assembler for a simplified virtual ... If you use locals then you have to initialise them each time. ... there are likely to be libraries that could be profitably used within ...
    (comp.lang.forth)
  • The never ending assembly vs. HLL war
    ... > branch instruction excluded is not particularly effective optimization. ... > CPU, chances are pretty good it *won't* be optimal on a different CPU. ... > discussing the futility of optimizing it in *assembler* when the ... careful and consider the code the compiler is emitting (and adjust your ...
    (comp.lang.asm.x86)
  • Re: the quality of assembly language code
    ... Intel's compiler is supposed to ... I have found that I prefer 'C' and assembler roughly in inverse ... >> code than human beings writing raw assembly language. ... > assembly programmers and compilers. ...
    (comp.lang.asm.x86)
  • Re: Microcontroller Project
    ... A C compiler will just mask the nonsense underneath. ... A heck of a lot of poeple will use C on micros because it provides many ... I still do some inline assembler where it's called ... Thousands of embedded engineers who use C almost exclusively will tell ...
    (sci.electronics.design)