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

Ravindra Divekar <ravindra@hal.com> writes:


> I've heard people say so many times, that hand-crafted (assembly) code
> is more compact than compiled C code for microcontrollers or DSPs.


In addition to other responses that were posted, here are a few more
points to consider.


1) debugging - Some real-time embedded developers insist on debugging
the binary image that was shipped with the product, and refuse to
debug images that can be created with other compiler command-line
options. (The rationale is that many defects are timing related, and
changes to the image will also change the timing).


Since few compilers support symbolic debugging and full optimization
in the same image, developers are forced to choose one or the other.
Shipping a high-volume parts-sensitive product without full
optimization is generally unacceptable, and debugging
compiler-optimized/generated code can be tedious. Some developers
choose to use assembly code and a coding style that is sufficiently
optimal and debuggable for thier needs.


2) volatile objects - A weakness in many optimizing compilers is code
generation for volative objects. Embedded applications commonly
communicate through hardware registers and memory mapped I/O, and
while ANSI C provides a mechanism to define objects that communicate
through these hardware devices, compilers do not always observe the
standard in this area (see
http://www.nullstone.com/htmls/category/volatile.htm for a more
detailed description).


3) difficult instruction sets - Some microcontrollers are very
irregular and can be quite difficult to generate efficient code. For
example, some microcontrollers have very specialized register sets;
others have tiny memory regions that are slower than registers and
faster than memory, and are accessed with a specific set of
instructions. Application-specific instructions (e.g. servo
calculation instructions) are sometimes difficult to compile to from C
(or HLL).


4) volume - While the embedded product may be high volume, compiler
developers generally receive revenue from the volume of embedded
developers, which may be relatively small. The resources that are
applied to developing the world's best optimizing compilers are not
uniformly available to all processor architectures.


Regards,
Christopher Glaeser cdg@nullstone.com
Nullstone Corporation http://www.nullstone.com
--

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