----- Original Message ----- From: "Grant Edwards" <gra...@visi.com> To: <mspgcc-users@lists.sourceforge.net> Sent: Thursday, March 16, 2006 4:22 PM Subject: [Mspgcc-users] Re: Large interrupt overhead?
> 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... > I haven't seen any reason to suspect that IAR's compiler will do significantly than gcc on the AVR, although it might be better in specific parts. A code difference of 50% strikes me as a bit high, but I haven't done any serious comparisons, and it will depend very much on the type of code. > > 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". > I take it you are also following the avr-gcc-list mailing list? Apparently you want to disable dwarf-2 debugging support to get it to compile. But it does sound like fun - I'm looking forward to when the msp430 gcc port moves to gcc 4.1. gcc 4.0 involved a lot of internal re-organisation in the compiler internal structures, but didn't do a great deal for the quality of the generated code (a few steps forward, and a few steps back) on most targets. It was made to provide the infrastructure for new optimisations and new functionality, which 4.1 has now started to implement. > > 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. :/ > Correct - unless you reserve a register specially for that use. > > * 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. > That's a little different. When the compiler starts to produce a block of code, it assumes certain pre-conditions, and makes sure these are still valid at the end of the block. These include things like it being safe to use scratch registers, and unsafe to use preserved registers without actively preserving them. The condition that __zero_reg__ is 0 and __tmp_reg__ is available happen at an even lower level - they are only broken over very short code sequences. For example, __tmp_reg__ will never (as far as I know) be used for anything other than loading immediate values into the low numbered registers. When compiling an interrupt function, the compiler must first establish these basic low-level conditions, and it seems to have no way to optomise them away. > > 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. > It's a different sort of optomisation at a different level. The __zero_reg__ usage is so that the code generator can pretend there is a true zero register, in the manner of many RISC processors (and the msp430's constant generator). Similarly, the __temp_reg__ is used so that the code generator can pretend that sequences like "ldi" or "andi" are valid for the low registers as well. They are not part of the register allocator system, which deals with preserving the used registers other than those two. Disclaimer - I haven't looked at the internals of avr-gcc, or any other gcc, so I might be getting things wrong here. I'm just surmising, based on experience with avr programming (assembly, avr-gcc, and ImageCraft icc-avr), examing generated assembly code, and using gcc on lots of other targets. > > 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 > > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting language > that extends applications into web and mobile media. Attend the live webcast > and join the prime developer group breaking into this new coding territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 > _______________________________________________ > Mspgcc-users mailing list > Mspgcc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mspgcc-users > > >
