Я Вам как раз по цитате. Вы вчера никак не могли себя убедить, как упаковываются данные, ссылаясь на какие-то внешние причины и т.д.
А вот теперь Ваша очередь убедит меня, как я вчера, что цитата, под которой Вы подписались- верна. Приведите пример листинга объявления переменных и соответствующий мап-файл, что бы это было очевидно. Сможете добиться такого результата, о чем так переживает автор приведенной Вами цитаты? Тогда и цитата Ваша будет чего-то стоить

Создайте в Кейле проект, выберите микроконтроллер (у меня был STM32F205VG), и посмотрите в map файл. При уровне оптимизации 0 имеем следующее:

При любом другом уровне - то же самое!

Хорошо, убедили.

Вообще то для того что бы расположить глобальные объекты в определенном порядке (еще и запакованные) есть global anonymous union


и все компилятор не сможет ничего никуда переставить!
правда вроде только в IAR такая конструкция может быть не static

Со структурами анонимус и не анонимус было понятно изначально. Тут речь шла о не связанных логически данных. Единственная их связь - одинаковое объявления в одном месте в программе. По умолчанию, кстати, в структуре данные тоже не упакованы.

Жаль, что это не соответствует стандарту c99, следовательно не панацея.

Это не связь! компилятор может их раскидать по своему усмотрению, особенно если оптимизация включена!
IAR например легко переменную может перекинуть даже в сегмент инициализированных данных из .bss (в отличии от GCC которая только обратно может если 0 значение)
И по стандарту С - только в структурах гарнируется порядок данных!


demiurg_spb,
В C11 уже есть анонимные структуры и объеденения, правда на счет глобальных непонятно.

Дурацкий вопрос: union-то зачем? Вполне достаточно одной только структуры.
Или это какая-то особенность IAR'а ?

с IAR'ом плотно не работал, анонимные структуры не использовал (хотя периодически хочется...).

IAR так описывал регистры периферии, может и без union работать будет.
Но в любом случае это не портабельно.

В Cortex-M3 выравнивание можно сказать, всегда нужно, читайте DDI0403D_arm_architecture_v7m_reference_manual_errata_markup_1_0. Unaligned access поддерживают только инструкции LDR, LDRT, LDRH, LDRHT, LDRSH, LDRSHT, STR, STRT, STRH, STRHT, но есть и другие, активно используемые компилятором, на пример LDM, которые сразу дадут UsageFault.
Я всегда устанавливаю UNALIGN_TRP, тогда любая инструкция, выполняющая Unaligned access даст UsageFault. чтобы быстрее баги отловить..
К стати в Cortex-M3 нету ущерба производительности при Unaligned access.
Такчто, если память будет использоватся компилятором, то выравнивание нужно обязательно, читайте IHI0042D_aapcs.
Единственное, где Unaligned access может быть полезен - это заполнение полей структур протоколов(USB, на пример), но делать это нужно ручками через __ldr()/__str() intrinsincs - что более предпочтительно - intrinsinc или ручками побайтно - решать вам.

Раз уж о выравнивании, то стек должен быть всегда выравнян до 8 байт, иначе при переходе на новый проц напоретесь на баги, тк "ARM deprecates implementation or use of 4-byte SP alignment." К тому же в IHI0042D_aapcs сказано: "Stack constraints at a public interface - The stack must be double-word aligned." (это при вызове публической функции, на пример).

Как эту ловушку использовать?

Вешаем обработчик на исключение UsageFault, а в нем уже делаем то, что нам нужно.

Понятно, спасибо.