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

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.


I think this is correct, but some researchers claim that this only
depends on that the compiler writers are lazy and incompetent...


>So where is the problem?


>Is it a limitation of existing compiler technology (so much for the
>optimization hype) ?


Compilers are generally better than humans in simple optimisations on
huge amounts of data, i.e. register optimisation and instruction
sceduling in RISC processors. Humans can change algorithm though,
which compilers generally cannot today. In the case of MCUs, the
essentials of the software consists of small routines, where humans
perform equally well or better than compilers.


Compilers normally use fixed calling conventions, like pushing
registers on the stack, whereas humans can optimize registers between
functions. This could be solved with inter-function register
allocation, but prohibits the use of precompiled libraries, which high
level languages rely on.


>Is it the choice of high level language i.e. C/C++ that matters ?


Not to a big extent. C/C++ isn't too complicated to translate to
assembly language. Standard C/C++ has problems computing with bits,
bytes and single precision floats, since the standard says that
everything should be converted to ints and doubles before computation
or function calls. Also booleans are represented as ints, not
bits. PL/1 might be a better language in that respect.


One problem is that a HLL programmer don't *want* to know about the
hardware architecture. If I write an algorithm in C, I would like to
be able to use it in both 8 bit and 16 bit MCUs. If I am programming
in assembly language, I *know* that my 8 bit MCU is lousy at 16 bit
arithmetic, and choose an algorithm without it.


>Is it the nature of application (scientific/real-time/control/float.pt)
>that creates porting problems?


Same as above. If I am programming in C, I don't want to know whether
my target supports floating point or not. In lots of cases the
programmer knows a lot more than the compiler about the expected
input. Example: The programmer knows that one input channel is
connected to a 7 bit ASCII terminal, which means that he can use the
eigth bit for something else. There are also constrictions like this
that i believe the compilers cannot optimize today:


do {
c = getc(f);
} while (c != 'Y' && c != 'y' && c != 'N' && c != 'n');
c = (c == 'Y') || (c == 'y');


No compiler that I know of can see that c is a boolean after this (I
might be wrong though).


> Or is it just the architectural features of typical microcontrollers
> that make things difficult ?


In some cases, HLLs require you to work around a problem that is
simple to solve in assembly language, like detecting carry/overflow in
arithmetic. This requires extra bits in C++ (or some funny looking
wrap-around check in a complex if statement), but is available
directly in condition codes in asm.


>thanx....Ravindra.


Well, I could go on forever, but this may give you a hint anyway...


Greetings --Jens


--

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