On 2006-03-16, David Brown <da...@westcontrol.com> wrote:
> As far as code size or performance is concerned, the AVR and
> MSP430 are actually not far apart for real code - the AVR code
> size is a bit bigger, but is often faster.
I compiled some largish functions several KB each and got AVR
codesize that was about 50% larger than MSP430 (using gcc on
both). For the smallish functions where I've counted cycles,
the actual execution times weren't too far apart. I'm beginning
to suspect that IAR on the AVR would do better, but I'm
dreading having to use AVR...
> Where it falls down is code that uses a lot of pointers,
> 16-bit or 32-bit arithmetic, flash memory access, or using
> small functions. The function call overhead of small
> functions is often reduced in practice by the optimiser
> inlining the functions - with the gcc 4.1 release with whole
> program optimisation, the compiler should figure out inlining
> and reduce prologues/epilogues even for cross-module funciton
> calls.
I'm might have to try that just for "fun".
> Small interrupt functions like your example are probably the
> worst possible comparison from the AVR's viewpoint. Some of
> the issues are:
>
> * The msp430 automatically preserves the status register on
> interrupts - with the avr, it must be done by code.
And you can't do it without getting a register dirty. :/
> * The avr-gcc people decided to use a __zero_reg__ (I don't
> think it is an overall win), and put it in r0. Since r0 is
> unavoidably used by other features (multipliers, and LPM
> instructions), it must be preserved in the interrupt
> prologue, since the compiler code generator assumes it is
> always valid.
That doesn't make any sense. The compiler is bright enough to
keep track of which "other" register get used and only preserve
the ones that are required, they must have added _extra_ code
to disable that for the zero reg.
> Similarly, it assumes that __tmp_reg__ is always available.
That's nuts. When there are other free registers, why dirty
__tmp_reg__ unnecessarily. The register scheduling in avrgcc
seems pretty broken.
> * There is (currently) no optimisation in the compiler to
> remove unnecessary parts of the interrupt prologue.
There must be, since it doesn't save the entire register set.
> I believe there are people looking at it, but I don't know
> any more.
>
> * The avr has no "eori" instruction, making the toggle code
> particularly cumbersome.
I did notice that a set/clr is a lot cleaner.
--
Grant Edwards grante Yow! I just remembered
at something about a TOAD!
visi.com
