[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: Georg-Johann Lay
Subject: Re: [avr-gcc-list] Align attribute in gcc requiring alignment of 2 for Xmegas with USB.
Date: Thu, 22 Nov 2012 11:04:33 +0100
User-agent: Thunderbird (X11/20100302)

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.



reply via email to

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