Re: [avr-gcc-list] Align attribute in gcc requiring alignment of 2 for Xmegas with USB.

[Georg-Johann Lay]

David Brown wrote:
> Georg-Johann Lay wrote:
>> 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 ?
>>
>> 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?

For BA, see the internals at [1].  To grasp the full meaning you want to have a
look at the compiler sources.

Johann


[1]
http://gcc.gnu.org/onlinedocs/gccint/Storage-Layout.html#index-BIGGEST_005fALIGNMENT-3881