avr-gcc-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-gcc-list] >4.5.1 better than this at register-structure (xmega)


From: Georg-Johann Lay
Subject: Re: [avr-gcc-list] >4.5.1 better than this at register-structure (xmega) access?
Date: Wed, 10 Oct 2012 22:43:01 +0200
User-agent: Thunderbird 2.0.0.24 (Windows/20100228)

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]