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

chuck@aage.mit.edu (Chuck Parsons)
22 Mar 1996 00:45:34 -0500

          From comp.compilers

Related articles
[37 earlier articles]
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? cdg@nullstone.com (1996-03-21)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? pdonovan@netcom.com (1996-03-21)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? fjh@cs.mu.OZ.AU (1996-03-21)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? cliffc@ami.sps.mot.com (1996-03-21)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? schwarz@mips.complang.tuwien.ac.at (1996-03-22)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? jfc@mit.edu (1996-03-22)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? chuck@aage.mit.edu (1996-03-22)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? preston@tera.com (1996-03-22)
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)
[7 later articles]
| List of all articles for this month |

From: chuck@aage.mit.edu (Chuck Parsons)
Newsgroups: comp.arch,comp.compilers,comp.dsp
Date: 22 Mar 1996 00:45:34 -0500
Organization: MIT Lab for Nuclear Science
References: 96-03-006 96-03-091 96-03-121
Keywords: C, performance

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?


sberg@camtronics.com (Scott A. Berg) writes:
|> 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.


elvey@hal.com (Dwight Elvey) writes...
>........ much deleted .........
> The best option is to do a mixture of high level and assembly
>code. This gets the best of both worlds. Any C compiler for DSP that
>doesn't allow inline assembly is so much waist.


    I might add that often compiliers for new micros are mot very
good. We have one for the 68hc16 wich is awful. Plenty of bugs like
forgetting to restore the page register on complicated if-then-else
structures and lots of unnecessary stuff that a good optomizer should
fix. We spent 2k$$ for this and really should get something
else. However, even though they pay me a fair amount, 5-10K$ can be a
lot for a startup company. Second to do a good eval would take a fair
amount of time, which is more money.




    I've speeded up Vax Fortran routines by studying the assembler the
_compiler_ wrote and then working on that. The Vax Fortran compilier
is pretty damn good, so it pays to start with its output and then
improve it. The compilier can definetely teach you a few tricks.


    I write most of my embedded code in C though I used to write it all
in assembler. However, I credit the hardware guys more than the
complier writers. If the assembler code is twice as fast as the
compilied code, the compilied code will be faster on next years
machine, and it _will_ be easier to port. Second, 1 megbyte of memory
is easy these days even on a small board that has to cost less than
$100. Using C in 16K goes pretty fast.


    Still I find to get the best performance (and you always need to to
be competetive) you have to get into the assembler world and
understand the pipe-lining and basic speed of the machine
instructions. More and more though, I find I can rewrite the C code
so it runs faster without writing the assembler directly. However, I
still have to study the assembler generated by the compilier and it
execution speed to do this. That is I have to write the code/algorthym
machine specifically. When I port to a new CPU the old C code runs
right away (big win) and the crucial speed loops can be rewritten
after there already is a functioning demo machine.


Cheers, Chuck@mitlns.mit.edu
--


Post a followup to this message

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