Re: C code .vs. Assembly code for Microcontrollers/DSPs ?

bobduff@world.std.com (Robert A Duff)
14 Mar 1996 17:20:30 -0500

          From comp.compilers

Related articles
[18 earlier articles]
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? mac@coos.dartmouth.edu (1996-03-08)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? cdg@nullstone.com (1996-03-08)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? regnirps@aol.com (1996-03-10)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? rjridder@knoware.nl (Robert Jan Ridder) (1996-03-10)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? rfg@monkeys.com (1996-03-14)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? sberg@camtronics.com (1996-03-14)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? bobduff@world.std.com (1996-03-14)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? bobduff@world.std.com (1996-03-14)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? john.r.strohm@BIX.com (1996-03-15)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? cdg@nullstone.com (1996-03-15)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? cdg@nullstone.com (1996-03-16)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? dan@watson.ibm.com (1996-03-16)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? stefan.monnier@lia.di.epfl.ch (Stefan Monnier) (1996-03-16)
[25 later articles]
| List of all articles for this month |

From: bobduff@world.std.com (Robert A Duff)
Newsgroups: comp.compilers
Date: 14 Mar 1996 17:20:30 -0500
Organization: The World Public Access UNIX, Brookline, MA
References: 96-03-006 96-03-025 96-03-049 96-03-070
Keywords: optimize

> [On small kernels, a skilled assembler programmer can certainly do better.
> On large programs, I'm not so sure. Compilers don't get bored as easily
> as we do, so they avoid making dumb mistakes. -John]


Christopher Glaeser <cdg@nullstone.com> wrote:
>And, superoptimizers can do better than skilled assembler programmers
>on short instruction sequences, where considerable computing resources
>can be applied to an exhaustive search. So, perhaps skilled assembly
>programmers do better on programs with enough complexity to preclude
>an exhaustive search, but small enough to avoid boredom and dumb
>mistakes.


The issue isn't just the length of the instruction sequence. The
issue is the amount of maintenance. Sure, on several hundred
instructions, I can do better than any compiler (given some time).
But when you're modifying existing code, you don't dare radically
change register assignments, for fear of introducing bugs. And so
forth. Even if the new code might be faster. Every time you
recompile it, the compiler does all that good stuff. But for
assembly, every time you re-assemble it, the original programmer is
long gone, or at least bored with the task.


One project I was on was to rewrite an assembler, which was written in
assembler, in a high level language. The stated performance goal was
to be no more than 30% slower than the earlier version (since
everybody knew there would be some cost). The actual product was more
than 10 times faster. I attribute this to the fact that the earlier
product had been maintained for some years, and therefor gathered all
kinds of dust.


>...If so, can it be said that optimization research and
>development is devoted, in part, to reducing the distance between
>these two end points?


Yes, in part. I view optimization not as making my programs faster,
but as allowing me to use higher-level language features, without
introducing too much cost.


- Bob
--


Post a followup to this message

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