Erik Walthinsen wrote:
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?
Such a bug has never been reported to the GCC bug tracker.
If nobody found it important enough to file a problem report for over 3
years (4.5 was released early 2009) I'd guess this is simply not an
important issue?
There is PR50448 which is similar but different and fixed for 4.7.0.
Xmega is supported in avr-gcc since 4.7.0 (PR52261) so you obviously use
some private port with its own, private bug tracker.
Johann
_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
