|[3 earlier articles]|
|Re: C code .vs. Assembly code for Microcontrollers/DSPs ? email@example.com (Eyal Ben-Avraham) (1996-03-03)|
|Re: C code .vs. Assembly code for Microcontrollers/DSPs ? firstname.lastname@example.org (1996-03-03)|
|Re: C code .vs. Assembly code for Microcontrollers/DSPs ? email@example.com (1996-03-04)|
|Re: C code .vs. Assembly code for Microcontrollers/DSPs ? firstname.lastname@example.org (Andrew Cruickshank) (1996-03-04)|
|Re: C code .vs. Assembly code for Microcontrollers/DSPs ? email@example.com (1996-03-05)|
|Re: C code .vs. Assembly code for Microcontrollers/DSPs ? firstname.lastname@example.org (1996-03-05)|
|Re: C code .vs. Assembly code for Microcontrollers/DSPs ? email@example.com (Risto Jokinen) (1996-03-05)|
|Re: C code .vs. Assembly code for Microcontrollers/DSPs ? firstname.lastname@example.org (1996-03-06)|
|Re: C code .vs. Assembly code for Microcontrollers/DSPs ? email@example.com (Ron Nicholson) (1996-03-06)|
|Re: C code .vs. Assembly code for Microcontrollers/DSPs ? firstname.lastname@example.org (1996-03-06)|
|Re: C code .vs. Assembly code for Microcontrollers/DSPs ? email@example.com (1996-03-07)|
|Re: C code .vs. Assembly code for Microcontrollers/DSPs ? firstname.lastname@example.org (1996-03-08)|
|Re: C code .vs. Assembly code for Microcontrollers/DSPs ? email@example.com (Tim Channon) (1996-03-08)|
|[40 later articles]|
|From:||Risto Jokinen <firstname.lastname@example.org>|
|Date:||5 Mar 1996 12:26:01 -0500|
|Organization:||Telecom Finland News Service|
email@example.com (Ravindra Divekar) wrote:
>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?
It is not a problem in the C-compiler of the microcontroller, it is
more problem if thinking. You can write most of code in C, but you
must be more careful with (at least) following items.
(microcontroller == 8/16 bit processor without fp suppor in this case)
- all algorihms must be adopted to use 8 or 16 bit arithmetic
- check support for signed arithmetic, if it is not supported,
use unsigned arithmetic by default. (BYTE/WORD/BOOL datatypes)
- parametre passing, how many paremeters can be passed in registers?
where return parameters are? what is correct parametre order?
- switch/case strures
how case labels are handled, how to order them?
- allow more global data, and also allow goto's if they are really needed.
- bit-field datatypes can be nice, but can cause _very_ slow code.
- You must know how processor works, to check critical parts from code-listing
>Is it a limitation of existing compiler technology (so much for the
>optimization hype) ?
- I'll say no. compilers can make good quality code, but bad algorithms can
cause problems. If you need to write code using microcontroller C, you
should be familiar of assembler/plm/c/forth, if you can handle those languages
( at least read them ) you can also write high quality/fast C-code.
>Is it the choice of high level language i.e. C/C++ that matters ?
>Is it the nature of application (scientific/real-time/control/float.pt)
>that creates porting problems?
There is one rule, 32bit dsp with fp support is easy for C. You can
verify most of code in pc, linux etc. 8/16 bits variants need more
>Or is it just the architectural features of typical microcontrollers that
>make things difficult ?
Yes, they are somehow too small for normal C-implementation, plm was
very good, forth also, and I have heard that some modula-2 compilers
are also good. the problem is that most of microcontrollers can not
handle C-style pointer algorithms that easy. (too few pointer
registers, and also problems with stack)
Return to the
Search the comp.compilers archives again.