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

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


Yes.


Computer science tends to deal with the gee whizz and doesn't want to
know about little systems which were buried years ago... yet those
outnumber everything else.


> 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


A lot of little systems don't like things like stacks, yet those are
the basis of a good deal of synthetic machines. We don't compile for
a processor, we compile for a non existant processor which is
interpreted by the real processor. How close it is varies... and for
embedded it tends to be far off. (okay, there are rare cases where
it's direct)


It is possible to compile for a computation stackless machine where
the memory is allocated from global memory. Parameter passing is done
using global. There are restrictions on what can be done, but I think
it is better to do the 90% which is possible and tell the user when
they ask for the impossible. Sorry, this sort of recursion isn't
allowed and can't be translated into iteration. I've asked one or two
whether work has been done on that sort of scheme, apparently not. I'm
surprised.


> The advantage of using compilers and high-level languages has never
> been efficiency of generated code, but ease and speed of programming
> and portability.


Agreed but not the portability because embedded etc. tends to be far
from portable.


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


Spot on. That's how we do it.


Fairly recently I designed a product where a 16 bit controller
(M37702) was tightly coupled to the hardware - I factored the problem
across the system resources I'd chosen for good cost
effectiveness. (an advantage of being multidisipline)


Digital audio is bus mastered into RAM, then processed in blocks to
reduce the interrupt rate and data output rate to managable
proportions.


The controller was coded in C (IAR). I'd already worked out that the
chip could handle the processing rate, although it would be fairly
close.


I was able to bring up the product fairly quickly in a degraded state.


By that time I'd already used a lot of trickery (that was intended). I
then spent a long time trying to persuade the compiler to generate
good enough code. I asked lots of people for ideas but in the end it
was a slog on my own. It wasn't possible to generate best code.


For embedded there are no niceties. It's common to use a lot of global
memory, rather like assembler programmers, so parameter passing is
something which can easily be avoided. A good saying here is "If it
looks hard, run away."


I decided to take the best so far, export it as assembler, and correct
the warts by hand.


It's heavily interrupt driven. It now runs fast enough, with a few
percent of free cpu time at worst case.... I hope.


The product is out there as part of a larger product. So far, zero
defects <sound of an angry telephone>


The coding language and compiler is not particularly important, whilst
the rest of the system is vital because we are dealing with real
hardware and a user who will want to do all sorts of crazy things. For
example, there is special RAM at that normally impossible address, use
it - it's actually hardware and not RAM at all. In this instance the
compiler is expensive, a normal situation with embedded and commercial
work. We are buying a whole system where the compiler is almost an
incidental! Amortising these costs can be hard and kills a lot of
minor projects, so I feel sorry for the little guys. It's possible to
hire, or use other financing schemes. This might seem far from
comp.compilers but it is an unavoidable subject in the real world... a
global optimisation perhaps. :-)


That job was probably more suited to DSP, but they are expensive (this
is the UK) and supply problems are endemic. I'd have had to code in
assembler and without the luxuary of lots of space and open heart
hardware.


    TC.
        E-mail: tchannon@black.demon.co.uk or tchannon@cix.compulink.co.uk
--

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