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

ravindra@hal.com (Ravindra Divekar) 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.


>So where is the problem?


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


>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?


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


I would say all of the above.


A problem with existing compiler technology is that many of the
optimizations are geared towards machines with a large number of
similar registers and where values tend to fit into single registers.
Many microcontrollers have a small number of registers, some of which
have special properties. Furthermore, compilers tend to use a fixed
calling convention, where a programmer can use special-purpose
light-weight conventions for different procedures. Also, C compilers
often don't use features specific to a particular processor very well,
as the back-ends of retargetable compilers may not be able to exploit
unusual features very well. A prime example is the bit-reversed
addressing found in some DSP's for use in FFT.


Part of the problem comes from using C/C++. One problem is the
requirement for separate compilation, which makes inter-procedural
register allocation difficult (though it can be done by postponing the
allocation to link-time, as showed by Watt). Another is the rather
free use of pointers, which makes some optimizations invalid unless
precise aliasing information can be obtained. A programmer using
assembler usually knows that a particular variable cannot be aliased
and hence does the optimization by hand. Furthermore, C compilers
typically use a small number of different sizes of integers, e.g. 8,
16 and 32 bit. An assembler programmer might see that only 24 bits are
needed, which allows him (on an 8-bit machine) to do operations on
these numbers more efficiently than in C. This problem is further
aggravated by the fact that the size of short, int and long depends on
the compiler/processor. I much prefer the Pascal idea of explicitly
specifying minimum and maximum values.


The application areas also play a part. Control operations are
typically very machine-specific and must hence be packed into a layer
of abstraction if it is used from a (portable) high-level language.
This layer costs efficiency.


The advantage of using compilers and high-level languages has never
been efficiency of generated code, but ease and speed of programming
and portability. Optimizing compilers makes it possible for the
compiler to generate code of a quality that is only feasible for
assembler programmers to exceed for small pieces of code. Hence, the
typical situation is that the majority of applications are written in
high-level langauegs, but small time critical or machine-dependent
parts are written in assembler.


I doubt that we will ever get compilers that never produce code that
can be improved by a good assembler programmer. But the assembler
programmer is likely to have to use increasingly more time to keep up
with the compiler in terms of efficiency.


Torben Mogensen (torbenm@diku.dk)
--

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