Я с ARM еще не работал, но у меня появились вопросы.
Если обьявить массив типа unsigned char в ОЗУ
сколько будет занимать один элемент в памяти?
Можно ли сделать так, чтобы он занимал 1 байт?
Если нет, то как легче всего это сделать программно.

"Массив char в физической памяти будет лежать так, как на это указывает #pragma pack, то бишь выравнивание, если 4, то каждый элемент массива будет расположен с адреса, кратного 4, то есть занимать 4 байта."
Давайте оставим впокое физическую память, будем говорить про память, адресуемую по скажем [R0] и пусть сама эта память лежит где хочет.
Так вот я утверждаю, что при инкременте R0 на единицу мы получаем доступ к следущему элементу массива. И никакие прагмы паки тут совершенно роли не играют. Не так ?
pragma pack является директивой выравнивания структур, она не имеет отношения к массивам. По крайней мере в части их размещения

Зависит от компилятора, размера элемента массива и установленного выравнивания !!!
Если мы говорим о массиве char, размер элемента равен 1.
Если мы установили выравнивание данных, равное 16, то, чтобы получить доступ к следующему элементу массива типа char, Вам в приведенном Вами примере придется увеличить R0 на 16.
В части различия компиляторов -- часть компиляторов применяет #pragma pack только к структурам, при этом для остальных типов у них есть что-то типа #pragma data_align. Это непринципиально. И обсуждалось уже здесь

И что ? Вы хотите сказать, что вашим шаманством я могу сделать такое -
char data[256];
printf ("%d\r\n" (int) &data[1] - (int) &data[0]);
и получить на экране 16 ? Сообщите пожалуйста такой удивительный компилятор и я посыплю голову пеплом
RVDS на этот счет говорит ясно
"There are no packed array types. A packed array is an array of objects of
packed type. There is no padding in the array."

ИМХО тут неправы Вы. Для программиста не так уж и всё прозрачно, если конечно он не на бейсике пишет.

На некотором подмножестве из всех имеющихся платформ.

Не всегда и не везде.

На x86 оно реализовано ради совместимости, на очень многих других платформах этого нет. А есть или исключения, или игнорирование младших битов (как в случае с ARM)
К томуже в тех же x86-расширениях (типа MMX/SSE/SSEx) есть команды допускающие только обращение к выравненным данным.

Применительно к char (на х86) чтение будет всегда одно.

PS а архитектуры всякие бывают, не надо всех под гребёнку x86 причёсывать.

SSE4 это хорошо... а что с моим вопросом ?

Ага, я понял. Мы говорим о разных вещах. Вы в приведенном примере путаете УКАЗАТЕЛЬ на элемент и АДРЕС элемента в памяти. Это разные вещи.
Операция & возвращает указатель на элемент, и результат будет равен 1. По сути, указатель - это всего лишь ИНДЕКС элемента в сегменте данных программы. Именно поэтому указатель всегда указывает на вполне ОПРЕДЕЛЁННЫЙ тип данных, чтобы компилятор мог правильным образом обслуживать арифметику указателей. Например,

Вас же не удивляет такая операция - указатель увеличился на 1, а указывает уже на 46 элемент массива double (что говорит о том, что адрес сместился на 8). Если Вы отпечатаете pDouble, то увидите, что он действительно увеличился всего на 1.
А изначально Ваш пример содержал регистр процессора R0, на уровне машинных кодов регистр косвенной адресации действительно увеличится на число, зависящее от размера элемента и от выравнивания данных.
Чтобы не продолжать спор, я готов его завершить, если Вы мне скажете, как я могу разместить массив char data[200000] с адресов, кратных 4, чтобы не делать лишнюю работу контроллеру 32 разрядной памяти при доступе к каждому элементу? Если, по Вашему, невозможно применить выравнивание к массивам ...

мы по прежнему друг друга не понимаем. Не можете. Можно указать что начальный адрес массивы будет с адреса кратного 4, но все char - ы в нем будут идти ПОСЛЕДОВАТЕЛЬНО и адрес последнего элемента будет N + (200000-1)
Перефразирую так. Имеем линейную память. 0,1,2,3,4,5,6,7....
Вы можете вашими директивами расположить массив чаров так, что [0] лежал в 0-й ячейке, а [1] в 4-ой ячейке ? Я утверждаю что нет

Как же , по Вашему, будут идти элементы массива, если размер каждого элемента равен 13, при установленном выравнивании (не важно какой директивой) 16?

через 13 байт. Слитно. Массива !
Будем продолжать спор, я пока что на RVDS и IAR проверил (вот дожил, очевидное проверять), и , естественно убедился, что в массиве структур никакого паддинга между элементами массива не будет

Попробую.

А вы смотрели на расположение в ROM или после инициализации в RAM? Насколько я понимаю в RAM с выравниваем 4, паддинг будет.

я смотрел в RAM и вообще причем тут ROM-RAM. Удаляем, как не относящееся к делу

Help на Borland C++ Bulder:

"The Data Alignment options let you choose how the compiler aligns data in stored memory. Word, double word, and quad word alignment force integer-size and larger items to be aligned on memory addresses that are multiples of the type chosen. Extra bytes are inserted in structures to ensure that members align correctly.
...
Byte alignment
When byte alignment is on, the compiler does not force alignment of variables or data fields to any specific memory boundaries. The compiler aligns data at even or odd addresses, depending on the next available address.

While byte alignment produces more compact programs, the programs tend to run slower. The other data alignment options increase the speed at which 80x86 processors fetch and store data.

Word alignment (2-byte)
When word alignment is on, the compiler aligns non-character data at even addresses. Automatic and global variables are aligned properly. char and unsigned char variables and fields can be placed at any address; all others are placed at even-numbered addresses.

Double word (4-byte)
Double word alignment aligns non-character data at 32-bit word (4-byte) boundaries. Data with type sizes of less than four bytes are aligned on their type size.
....
"
и т.д.

И чего ??? где тут слово array ? Я только structures вижу. Люди, кончайте дурку валять пудрить мозги говорить на разных языках, назовите мне компилятор, который решетом массив разместит

По поводу игноригования младших битов адреса в ARM-е я пожалуй погорячился. Всё немного хитрее.
хитрый пример (GCC и LPC2292)



Выдаёт:


А теперь угадайте что выдают на печать первый и второй циклы?
Одно и тоже? Какбы не так:


В первом случае компилятор знает что элемент data[n].ui не (всегда) выровнен на границу слова, поэтому читает слово ЧЕТЫРМЯ!!! инструкциями ldrb, и из этих 4-х байт "собирает" слово.
Во втором случае компилятор предполагает что pui - указатель на выровненное слово и читает сразу слово командой ldr. И вот тут вылазит особенности ARMа по работе с невыравненными данными. По сути младшие 2 бита адреса слова используются как количество байт на которое циклически сдвигается прочитанное слово.


А с точки зрения голых Сей результат должен быть одинаковый.
Т.ч. ИМХО программер должен много чего знать по части платформы, компилятора и т.д.