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

sberg@camtronics.com (Scott A. Berg)
31 Mar 1996 17:20:25 -0500

          From comp.compilers

Related articles
[45 earlier articles]
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? bobduff@world.std.com (1996-03-22)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? torbenm@diku.dk (1996-03-25)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763) (1996-03-25)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? schwarz@mips.complang.tuwien.ac.at (1996-03-25)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? pardo@cs.washington.edu (1996-03-25)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? mgrice@iastate.edu (1996-03-27)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? sberg@camtronics.com (1996-03-31)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? nather@astro.as.utexas.edu (R. Edward Nather) (1996-04-02)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? ok@cs.rmit.edu.au (1996-04-02)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? sberg@camtronics.com (1996-04-06)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? ok@cs.rmit.edu.au (1996-04-10)
| List of all articles for this month |
From: sberg@camtronics.com (Scott A. Berg)
Newsgroups: comp.arch,comp.compilers
Date: 31 Mar 1996 17:20:25 -0500
Organization: Alpha.net -- Milwaukee, WI
References: 96-03-006 96-03-110 96-03-139
Keywords: optimize

> in other words, even the programmer that wants his code to go fast
> should concentrate on the readability of his code more than on using
> tricks like '+='.


cliffc@ami.sps.mot.com says...
>Yes. Readable code is much easier to do performance analysis on,
>which can lead to algorithmic changes for big-O speedups (to say
>nothing of what the programmer that follows you thinks of your code).


Well in general I agree, but no one seems to have covered the all too
common dead end. Suppose you want to sort a list of a few hundred
seemingly random integers (no special properties to exploit like being
generated in almost sorted order) and you are already using quicksort
(or some other O(n log n) algorithm) and it's still too slow. There
ARE no faster algorithms and diddling with the code to squeeze a few
constants can make the difference.


Besides, I've rarely run into the need for such a distinct function as
a list sort or a string search or some other "classroom example"
algorithm, and deriving minimal big-oh algorithms is rarely a pastime
in industry.


Bottom line:


1) There will always be a need for assembly language bit-jocks, but
both the demand and the supply pool will get smaller.


2) There will always be a need for board layout experts, no matter how
many auto-routers are on the market.


3) There will always be a need for a good auto mechanic, no matter how
electronic the ignition gets.


4) And so on. Perhaps creating this list would be another good thread!
--
Scott A. Berg
--


Post a followup to this message

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