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

sberg@camtronics.com (Scott A. Berg)
14 Mar 1996 17:04:47 -0500

          From comp.compilers

Related articles
[17 earlier articles]
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? hbaker@netcom.com (1996-03-08)
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)
[33 later articles]
| List of all articles for this month |

From: sberg@camtronics.com (Scott A. Berg)
Newsgroups: comp.arch,comp.compilers,comp.dsp
Date: 14 Mar 1996 17:04:47 -0500
Organization: Alpha.net -- Milwaukee, WI
References: 96-03-006
Keywords: C, performance, comment

ravindra@hal.com says...
>I've heard people say so many times, that hand-crafted (assembly) code
>is more compact than compiled C code for microcontrollers or DSPs.
>
>So where is the problem?


I have been writing embedded hard real time system software for about
10 years, and I believe the claim that, when speed is paramount, a
good assembly programmer does better than a good compiler. I believe
this is due to several things.


1 - Lousy C code can fool a compiler into thinking no optimization is
possible. There is only so much "smarts" possible with compilers.
For example, common sub-expression extraction can be fooled by using
parentheses "for clarity" but which fool the parse tree into thinking
two equivalent expressions are different.


2 - C includes some under-used features to help the compiler.
"register", "static" and "const" are three keywords that can have a
major impact on resulting code, but they are used too little due to
their not being well understood.


3 - The ability to assign a value as part of an if statement, e.g., if
(x=(y+2 > z)), was designed to make it easy for the compiler to spot
when an expression value can be assigned to a register and used for
several operations. This construct is seldom used because it can be
confusing. LINT usually throws a fit over this one. Thus, a feature
that is useful for speed is seldom used due to clarity.


4 - The RISC architecture introduced the idea of LOTS of registers
which make it easier to save partial results in very fast memory for
later reuse. Compilers have not fully caught up with this. Besides,
since "most software today" runs on CISC processors like the 80x86 and
680x0, the registers available to the programmer are fairly few.


I just heard a lecture by Peter Dibble, PhD of Iowa State University
and Microware where he stated that a good assembly language programmer
can consistently write code that takes up to 30% less execution time
than code generated by a compiler. He has a long list of examples.
He is also quick to add that this sort of code takes a VERY long time
to write, requires a huge amount of obscure knowledge and experience,
is often difficult to understand, and should be used sparingly.
--
Scott A. Berg
[Do people really not use const and static? And are there still compilers
that pay attention to register? -John]
--


Post a followup to this message

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