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

[Erik Walthinsen]

On 10/10/2012 02:24 PM, Weddington, Eric wrote:
> Johann is being pedantic. Atmel has their own set of patches, i.e. it *is* a 
> private port, because those patches aren't fully submitted upstream yet.
> I'm working on getting Atmel's patches upstream.
In the meantime (I'm assuming the delay is the gcc team), any chance of 
making the set available directly in some "official" location?  If I'm 
going to have any chance of upgrading my toolchain I do not have time to 
try to extricate everything out of the available Atmel source trees, if 
they're even remotely up to date in the first place.

> But specifically to your problem: I've had a latent concern about the xmega 
> register definitions via structure layout. My concern is that the compiler 
> would do exactly as you describe and always try to do an address/offset type of 
> access to registers.
Concerns as far as whether it should be done at all?  I have to say that 
not having those structures would have made my source very unmanageable. 
 My hardware.h file says things like:

#define ADS1281_SPI SPID

and if my PCB design changes and moves it to another port, I just change 
the header to match the new revision.  Right now I'm even running a the 
exact same codebase on two different hardware revisions that have 
different PCB pinouts but are otherwise schematically identical.  That's 
one of the key things I love about the Xmega specifically is the 
*almost* perfect interchangeability of the ports.

I even have a header file that I've built up over time that does things 
like:

USART_PORT(USARTC0) -> PORTC
USART_TXD_bp(USARTC1) -> PIN7_bp

They basically take the address of the structure (since USARTC0 etc is 
fundamentally an address) and do an ? : chain to return what I wanted 
entirely at compile-time.

Also, in the ARM works CMSIS makes register-structures a de facto 
standard....

> But as you said: Does it do that with recent versions? I'm afraid that no one 
> yet knows.
If I get a chance to build a new (stock) toolchain with the latest 
binutils/gcc/avr-libc I'll try to find out.

In the meantime I hacked up a macro that gets me the effect ("fast-struct"):

#define FS(s,m) (*(typeof(s.m) *)((void *)&s + offsetof(typeof(s),m)))

timer = CYCLECOUNTER_MILLISEC.CNT     // "slow"

timer = FS(CYCLECOUNTER_MILLISEC,CNT) // "fast"

Now I'd love to know why LAS/LAC instructions don't seem to work, but 
that's an investigation for later.