Re: Align attribute in gcc requiring alignment of 2 for Xmegas with USB.

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:
>> Hi,
>>
>> 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 ?
>
> Yes.
>
>> 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.
>
> Johann

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?

David