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

[Georg-Johann Lay]

Erik Walthinsen schrieb:
> Georg-Johann Lay wrote:
> > Such a bug has never been reported to the GCC bug tracker.
> Well then, I guess I need to file one.  I just have no idea how to 
> actually fix it, and no time to do so at this point ;-(

Same here.  I have no idea why this is not optimized.

But to make sure we know what we are talking about, here is a test case.

typedef struct
{
    unsigned char volatile CTRLA;
    unsigned char volatile CTRLB;
    unsigned char volatile CTRLC;
    unsigned char volatile CTRLD;
} TC0_t;

void tc0_writeC (void)
{
  (*(TC0_t*) 0x0800).CTRL = 0;
}

Remember that GCC developers don't know what "TCC0" or "CTRLE" is.
They don't even know what "AVR" stands for.

Compiling that with

$ avr-gcc -mmcu=atmega8 foo.c -S  -Os

gives us

tc0_writeC:
        ldi r30,0
        ldi r31,lo8(8)
        std Z+2,__zero_reg__
        ret

        .ident  "GCC: (GNU) 4.8.0 20120915 (experimental)"

The generated code is the same for 4.3, 4.5, 4.6, 4.7 and 4.8.

> > 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?
> It's not a bug per se but a missing optimization, so it's entirely 
> possible nobody's cared enough to check.

There are no avr-gcc developers.  I am trying to fix some wrong code 
bugs in my spare time but it is impossible to permanently monitor what 
the compiler is doing with optimizations.  Not for a volunteer like me.

Moreover, I don't use Xmega and probably will never ever use it because 
the classic devices are so much more convenient for my hobby projects.

> > There is PR50448 which is similar but different and fixed for 4.7.0.
> Yeah, doesn't look like the same issue at all.

Well, the artifact is the same: Indirect access where direct addressing 
is available, and it's only for volatile accesses.

> > Xmega is supported in avr-gcc since 4.7.0 (PR52261) so you obviously use
> > some private port with its own, private bug tracker.
> No, I'm using a version that matched the latest toolchain source I could 
> get from Atmel at the time (6-12mo ago?) and took their patches 
> including Xmega, which didn't include any more than the 64a1u, 128a1u, 
> and 256a3bu.

Private port then.  It's not from sources hosted in the FSF GCC repository.

> I had to go through *all* the toolchain to add in the rest 
> of the parts that are available from Digikey.

This is a one-liner in the compiler [1] and in binutils [2].
In AVR-Libc you have to compile the crt*.o from the startup-code [3] and 
get or copy-past-patch a device header and compile libc.a and libm.a.

Alternative approach is that you only use Standard-C features from Libc, 
get device header and startup code.  Because the compiler supports, say, 
-mmcu=avrxmega6 you can compile, assembler and link with that option, 
can set -D__AVR_Device__ by hand and are done.  Everything you need is 
to link against the right crt*.o that you compiled from [3] above.

Because you use a device where core support is available and restrict to 
Standard-C, the multlilibs contain a libgcc.a, libc.a and libm.a that 
works with your core and are automatically picked from the -mmcu=<core> 
option.

> So, I guess I'll ask again: where do I actually get TODAY's toolchain?

GCC and Binutils and AVR-Libc are source projects and thus distributed 
as source.  See "Download" resp. "Obtaining" on the project front pages:

http://gcc.gnu.org
http://sourceware.org/binutils
http://nongnu.org/avr-libc

Johann


[1] <GCC>/gcc/config/avr/avr-mcus.def
[2] <Binutils>/gas/config/tc-avr.c
[3] <AVR-Libc>/crt1/gcrt1.S