Something I've found and would like to get dealt with is the fact that
avr-gcc 4.5.1 doesn't seem to properly comprehend the Xmega structures
in avr-libc when it comes to efficiently loading and saving them. It
uses a pattern of loading the struct address into an address-register
pair, then using offset load/store. Sometimes I've even seen it waste
*four* registers loading the struct address and adding a 16-bit offset
before doing a full indirect load/store. However, if I use the _
versions of the register definitions it does the efficient thing and
lets the compiler calculate the address directly resulting in a single
instruction:
void structwrite(uint8_t v) {
TCC0.CTRLE = v;
a6c: e0 e0 ldi r30, 0x00 ; 0
a6e: f8 e0 ldi r31, 0x08 ; 8
a70: 84 83 std Z+4, r24 ; 0x04
}
a72: 08 95 ret
void straightwrite(uint8_t v) {
TCC0_CTRLE = v;
a74: 80 93 04 08 sts 0x0804, r24
}
a78: 08 95 ret
(and yes, I see this behavior *everywhere* I look, not just in simple
examples like this)
This is a royal pain when I have my hardware-description header full of
things like:
#define MILLISECOND_TIMER TCC0
and code that wants to *consistently and quickly* access any arbitrary
(but static at compile-time) member of that peripheral's structure.
Instead I'm having to make a complete mess of my header with:
#define MILLISECOND_TIMER_CCA TCC0_CCA
rather than just using MILLISECOND_TIMER.CCA and being done with it.
So, my question is: is this fixed in a newer version of the compiler,
and thus worth my time to try to a) find all the patches, b) update my
own patches for the various -U xmega chips, and c) compile the whole
lot? Or, is this problem still present?
_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
