Ньюансы IAR-а, Alignment Опции

[Twen]

Здравствуйте. Есть директива #pragma pack(), упаковка структуры не совсем понятен параметр функции pack (1,2,4,8 или 16)...а IAR(msp) записует переменные в память ОЗУ по чётным адресам так как указатель двухбайтовый (это связано с архитектурой msp)? На сколько я понимаю из-за этого и нужно применять выравнивание ? И объясните пожалуйста использование директивы #pragma data_alignment=(1,2,4...)...вообще непонятно всё, что связано с alignment...
Заранее спасибо )


Также есть вопрос по поводу битового поля.
struct fff {
unsigned char first : 1; //1 -количество бит в поле
unsigned char second : 1;
unsigned char third : 1;
unsigned char forth : 1;
unsigned char fifth : 1;
unsigned char sixth : 1;
unsigned char sevnth : 1;
unsigned char eighth : 1;
};
a=sizeof(struct fff); //a=1;

а если изменить на int 2 бита

struct fff {
unsigned char first : 1; //1 -количество бит в поле
unsigned char second : 1;
unsigned int third : 1;
unsigned char forth : 1;
unsigned char fifth : 1;
unsigned int sixth : 1;
unsigned char sevnth : 1;
unsigned char eighth : 1;
} ;
то

a=sizeof(struct fff); //a=10;


Не понятно, почему размер структуры стал 10 байт???

Заранее спасибо )


Сообщение отредактировал Twen - Dec 8 2010, 09:40

[Twen]

Добрый день. Опять возвращаюсь к этой теме, мне не дает покоя непонимание некоторых вещей, так как знакомых опытных программистов у меня нет, пишу опять сюда.
На сколько я понимаю, размер типа int зависит от архитектуры процессора, для 32 разрядных это 32 бита, для 16 - 16 бит. Аналогично от платформы зависят и целые типы short, long. Например для Cortex M3 я проверял в иаре int = 4байта, short = 2, long = 4!(тоже что и int)!!! Возникает вопрос, есть ли еще какие-то плаформо-зависимые типы ?
Второй непонятный момент, как происходит выравнивание я понял, благодаря высшее описанному разговору, но...
Для примера возьмем cortex M3/
1.Есть внутренняя память Flash и ОЗУ, доступ к ней обеспечивается через 32 разрядные шины данных и адресную. Выходит для того, чтобы прочитать байт, процессор должен вычитать 32 разрядную ячейку и отбросить лишнее, а для записи процессор должен : Read 32 (0x 11 22 33 44) ->( (0x 11 22 33 44 & 0xFF FF FF 00) | Byte) -> записать результат. (считать 32 разр. ячейку, сделать логическое "&" а потом "|" c байтом и записать результат)?
Я смотрел аcсемблерные команды для Cortex M3, там есть команды чтения, записи байта, слова...ну они наверное не так реализуются, как я описал, так бы было очень не производительно.

2.Если в памяти по умолчанию производиться выравнивание к адрессу кратному 4, то выходит, что если у нас есть RAM = 1кБт (это 256 32-ух разрядных слов) , при использовании в программе 256 переменных типа char, получилось бы, что память стала полностью заполнена, а реально мы использовали только 1/4 памяти.
Если в командах ядрах есть доспуп к любой ячейки памяти, то зачем тогда выравнивать вообще? Если процессор может понять, что структура была упакована, то почему компилятор сам не пакует так данные размещенные у RAM?

Спасибо.

Сообщение отредактировал Twen - Oct 26 2011, 08:07

[Сергей Борщ]

Возникает вопрос, есть ли еще какие-то плаформо-зависимые типы ?

char (должен быть не меньше восьми битов, больше - пожалйста. float и double могут быть по 32 бита. Короче - все базовые типы.

Если в командах ядрах есть доспуп к любой ячейки памяти, то зачем тогда выравнивать вообще?

Не во всех архитектурах невыровненый доступ дается бесплатно. Разве что на 8-битках. Но поробуйте организовать такую структуру - и получите те же проблемы на AVR:

CODE

struct test
{
   uint8_t   a:6;
   uint8_t   b:4;
   uint8_t   c:6;
}

Обратитесь к элементу b этой структуры и почувствуете в листинге примерно то же, что многоразрядные процессоры чувствуют при невыровненном доступе.
Кое-где он может занимать больше времени (потому что все "волшебство" спрятано внутри ядра), где-то компилятор будет вынужден считывать каждую невыровненную переменную побайтно и в регистрах из нескольких байтов собирать одно большое число. Ну представьте себе, что у вас память снаружи и соединена 16-битной шиной. И если переменная не ложится ровно на шину данных - то процессору в любом случае придется делать несколько обращений, выбирая разные адресные входы.

Если процессор может понять, что структура была упакована, то почему компилятор сам не пакует так данные размещенные у RAM?

Вы можете заставить компилятор работать с со всеми структурами в упакорванном виде, но это будет такой стоп-кран, что лучше пожертвовать немного ОЗУ, только пусть он разложит данные так, как ему удобно. Он же тоже не дурак, и выделять по 4 байта на каждую вашу переменную не будет.

Доверьтесь ему, и используйте пакованные структуры только там, где это действительно нужно - при обмене с внешним миром.