Размер unsigned int или int Keil4.5 Опции

[TAutomatic]

Добрый день, коллеги.
Месяц использую LPC1768 и только сейчас с "ужасом" заметил, что под переменные unsigned int и int компилятор отводит по 4 байта.
Использую среду Keil 4.5 и постоянно плююсь даже не по причине ее скудости, а по причине неудобности документации на нее и компилятор. Как установить "нормальный" размер этих типов данных размером в 2 байта?
И второй вопрос. Я был уверен, что в Cortex-M3 отсутствует необходимость выравнивания разноразмерных типов данных.
Об этом написано тут
Тем не менее, у себя в реале я этого не вижу. Если за однобайтовой переменной следует четырехбайтовая, то она все равно выравнивается по границе 32 разрядного слова, тоесть остается неиспользуемый промежуток в 3 байта. Что тут не так?

[aaarrr]

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

[prottoss]

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

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

Код

__packed char a;
__packed short b;
__packed long c;

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

Char может быть расположен как угодно - на скорости это не скажется.

Код

__paced short a;
__packed char i;

for(i = 0; i++; i < MAXCYCLE)
{  
   ....
}

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

[aaarrr]

С переменной 'c' и так все ясно, она 32-бит и компилятор положит ее в память по выровненному 32-бит адресу.

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

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

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

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

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