|
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: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
[Prev in Thread] | Current Thread | [Next in Thread] |