Подождите, я Вам также и возразил. Пакед относится к структурам, а не к базовым типам данных. А Вы утверждаете ниже, что и к базовым типам тоже применимо. А приводите в пример все же структуры. Давайте отделим мух от котлет. Со структурами все понятно.
Базовые типы упаковать как можно? есть у вас ответ? Если у меня есть в разных программных модулях глобальные переменные, но в пределах видимости определенных модулей, на кой их мне сносить в одну гигантскую структуру? Это что- удобно? А вот что бы переменные были упакованы - тоже необходимо. Эффективность работы с такими переменными-второй вопрос. Первый - размер в ОЗУ.

Сами решили не пробовать даже?

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

Наверное все же
?
Хотя я сам такой ерундой не баловался

Нет. Какой смысл паковать char, если он и так упакован по определению?


Позволит разместить переменную без выравнивания. Глобально подобные вещи не практикуются, т.к. такой подход просто убьет производительность.
Аккуратно размещать данные, чтобы не было перерасхода на padding'и, программист должен самостоятельно.

Я почему то думал, что компилятор два "char" ('a' и 'c') упакует в одно 32-бит слово, а 'b' поместит в другое.

Но вот работа с этими самыми 'a' и 'c' - это очевидно - будет достаточно медленна.

Char может быть расположен как угодно - на скорости это не скажется. А вот short, int и т.п. лучше выравнивать, что компилятор и делает по умолчанию.

Стоп-стоп. Что то я Вас не понимаю... Зачем выравнить 'int' если он по умолчанию и так ляжет в 32-бит слово??? То же самое относится к типу 'long'. Для 32-бит систем эти типы одинаковы по размерности.
А вот как раз с 8/16-бит переменными ('char' и 'short') сложности по производительности.
Допустим, вы объявили три переменные трех разных типов:

С переменной 'c' и так все ясно, она 32-бит и компилятор положит ее в память по выровненному 32-бит адресу.
С переменными 'а' и 'c' начинаются сложности. Компилятор положит их в 32-бит ячейку вместе. Т.е. у одной из переменных, в зависимости от решения компилятора будет не выровненный адрес. У какой - не известно Все зависит от интеллекта компилятора... Возможно, я заблуждаюсь?



Интересно, скажется ли на производительности цикла то, в каком байте 32-бит слова будет расположена переменная 'i'? В младшем из 4-х байтов или в 3-ем?

Нет, ведь мы позволили разместить ее как угодно (__packed).


Объясните мне, как у char'а размерностью один байт может быть не выравнен адрес?
Если вы объявили переменную как __packed, компилятор по определению работает с ней как с не выравненной, несмотря на реальный адрес.


Разумеется, нет.

Все, от перегрева на солнце, я погнал. Извините. Вы, безусловно, были правы.

Чтобы сомнения не терзали, предлагаю обращаться к первоисточнику. Понятно, что это скучно и не позволяет поговорить "за жизнь", но информацию даёт на ура.

Первый мой рабочий день новой недели позволяет мне Вам сказать спасибо. Действительно, квалификатор пакует, убедился своими глазами. Честно говоря, как для меня, документация KEIL на свою среду не очень удобна. Наверно, дело привычки. Сразу в хелпе, что идет со средой не разобраться. На сайте кажется даже более удобно. Но это лично мое мнение, нет повода для споров. А вам, aaarrr еще раз спасибо.

Я бы предложил не заниматься всякой фигнёй. Особенно если нет твёрдого понимания, что вообще происходит.
__packed, конечно, экономит память, но заметно сказывается на объеме программы (на не-кортексах) и на производительности (на любых армах).

Кейл (в частности, 4.14 с включенным оптимизатором) достаточно догадлив, чтобы собрать данные в одну кучу.

А я бы постеснялся давать такие советы. Я думаю, на "месте" виднее, "фигня или не фигня". Для кого-то аккуратность распределения памяти, а для кого-то фигня. Но давать такого рода советы вместо технических - отсутствие воспитания. А насчет твердого понимания - это наверно из соседней темы? :-)

Кейлу следовало бы быть более тщательным в своей "догадливости" и разместить данные в порядке: var_b, var_a, var_c. Т. е. без разрыва, который в Вашем примере имеет место быть.