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

On 22/11/2012 11:04, Georg-Johann Lay wrote:
> 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
>

I've tried a little research (though I certainly haven't looked at 
everything - just started with google and worked from there).  I have 
found a couple of cases where it is used.  If you specify 
"__attribute__((aligned))" without any explicit value, the object is 
aligned to BIGGEST_ALIGNMENT.  A number of other settings, such as 
MAX_OFILE_ALIGNMENT, default to BIGGEST_ALIGNMENT.

Assuming MAX_OFILE_ALIGNMENT is set to a larger value (so that the 
"aligned" attribute will work), I can't see any reason for 
BIGGEST_ALIGNMENT to be larger than 1 byte on the AVR.

But I think I still haven't grasped the point of BIGGEST_ALIGNMENT.  I 
guess I'll have to do some more reading this evening.

mvh,.

David