Jump to content

    
Sign in to follow this  
TAutomatic

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

Recommended Posts

Вам же выше уже говорили про __packed. Создаете структуру с требуемым набором данных. Сообщаете компилятору, что нужно ее упаковать и готово.

Подождите, я Вам также и возразил. Пакед относится к структурам, а не к базовым типам данных. А Вы утверждаете ниже, что и к базовым типам тоже применимо. А приводите в пример все же структуры. Давайте отделим мух от котлет. Со структурами все понятно.

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

Share this post


Link to post
Share on other sites
Подскажите метод, как упаковать?

unsigned char A;
unsigned long B;
unsigned char C;

что бы получилось занятыми в памяти не 12 байт, а 6 байт?

Буду весьма благодарен.

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

unsigned char a;
__packed unsigned long b;
unsigned char c;

Share this post


Link to post
Share on other sites
Сами решили не пробовать даже?

unsigned char a;
__packed unsigned long b;
unsigned char c;

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

Share this post


Link to post
Share on other sites
Наверное все же

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

 

Но меня чисто теоретически гложат смутные сомнения, что дает этот квалификатор применимо к одной строчке?

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

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

Share this post


Link to post
Share on other sites
Нет. Какой смысл паковать char, если он и так упакован по определению?
Я почему то думал, что компилятор два "char" ('a' и 'c') упакует в одно 32-бит слово, а 'b' поместит в другое.

 

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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-ем?

Share this post


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

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

 

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

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

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

 

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

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

Share this post


Link to post
Share on other sites
Объясните мне, как у char'а размерностью один байт может быть не выравнен адрес?
Все, от перегрева на солнце, я погнал. :) Извините. Вы, безусловно, были правы.

Share this post


Link to post
Share on other sites
Но меня чисто теоретически гложат смутные сомнения, что дает этот квалификатор применимо к одной строчке?

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

Share this post


Link to post
Share on other sites
Нет. Какой смысл паковать char, если он и так упакован по определению?

 

 

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

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

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

Share this post


Link to post
Share on other sites

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

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

 

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

 

volatile char var_a;
volatile int var_b;
volatile char var_c;
int main(void)
{
    var_a = IOPIN0;
    var_b = IOPIN1;
    var_c = var_a + var_b;
    IOPIN0 = var_c;
    while (1);
}

 

    var_a                                    0x40000000   Data           1  main.o(.data)
    var_c                                    0x40000001   Data           1  main.o(.data)
    var_b                                    0x40000004   Data           4  main.o(.data)

Share this post


Link to post
Share on other sites
Я бы предложил не заниматься всякой фигнёй. Особенно если нет твёрдого понимания, что вообще происходит.

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

 

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

 

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

Share this post


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

    var_a                                    0x40000000   Data           1  main.o(.data)
    var_c                                    0x40000001   Data           1  main.o(.data)
    var_b                                    0x40000004   Data           4  main.o(.data)

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this