Перейти к содержанию
    

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Подскажите метод, как упаковать?

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Наверное все же

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

?

Хотя я сам такой ерундой не баловался :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Наверное все же

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

 

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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-ем?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

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

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

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

 

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

__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)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Кейл (в частности, 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. Т. е. без разрыва, который в Вашем примере имеет место быть.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...