[Top][All Lists]

[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: Thu, 11 Oct 2012 09:04:17 +0200
User-agent: Thunderbird (Windows/20100228)

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

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

        .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:



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

reply via email to

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