[Top][All Lists]

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

Re: [avr-gcc-list] Align attribute in gcc requiring alignment of 2 for X

From: David Brown
Subject: Re: [avr-gcc-list] Align attribute in gcc requiring alignment of 2 for Xmegas with USB.
Date: Thu, 22 Nov 2012 09:50:44 +0100
User-agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/17.0 Thunderbird/17.0

On 21/11/2012 21:36, Georg-Johann Lay wrote:
Hi, would you avoid TOFU style in the lists? Thanks.

Otherwise we will soon lose track of a conversation.

Thomas, George schrieb:

I checked the patches of the fix in PR53448

Even when the requested alignment in greater than the
BIGGEST_ALIGNMENT (considering it to be 2 for Xmega and 1 for other
devices), we are not producing a warning to the user that he is
trying to align more than the required. Is this behavior right ?


Should the warning be there in this case ?

No.  If alignment is bigger than BIGGEST_ALIGNMENT, then code will still
be all right; just a bit more memory consuming.

However, some hardware might need a more restrictive alignment, you
named an example.  To arrange for that, the user can align data by hand.

This align-by-hand will be an exception and is not commonly needed for
code that runs on xmega.

On a strict-alignment platform like ARM, you would set BIGGEST_ALIGNMENT
to 32 or maybe even 64 for 64-bit ARMs.

If alignments are less restrictive than BIGGEST_ALIGNMENT you will get
wrong code, e.g. for variables located in memory.  Because on AVR there
are no restrictions, BIGGEST_ALIGNMENT is 8.

In the case where the user wants to align, say, an I/O buffer, she can
use the alignment attribute to arrange for that exception to the rule,
and no diagnostic should be issued then because the user explicitly
asked to align the object.


Forgive me for my ignorance here, but what use is "BIGGEST_ALIGNMENT"?

Each type has a /minimum/ alignment and a /preferred/ alignment, dependent on the type, its size, the target cpu, and perhaps other details (such as memory buses or other internal structures). For example, a 32-bit int might require 4-byte alignment on one target, but be fine with 1-byte alignment on another, and on a third target it might work okay with 1-byte alignment but be faster with 4-byte alignment.

On the other hand, there are times when the user explicitly wants to /increase/ the alignment of an item, using the "align" attribute. I can't remember having used this on an AVR, but I've used it on other processors, such as to align data with cache lines or to match DMA buffers. And I could imagine uses on an AVR also - if you want a fast circular buffer or lookup table, you might use 256-byte aligned 256-byte arrays to allow you to do indexing using 8-bit calculations instead of 16-bit.

I /love/ compiler warnings, and enable almost all of them - but if I explicitly use an "align" attribute to align data at 256 bytes, I don't want a warning telling me it is unnecessary, or bigger than "BIGGEST_ALIGNMENT". And I certainly don't want a warning telling me the compiler is refusing to match my requirements just because it is bigger than "BIGGEST_ALIGNMENT".

So where does "BIGGEST_ALIGNMENT" fit in?


reply via email to

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