Откуда взялись лишние 3 байта!? В чем может быть причина?

Project Options/Advanced Compiler/Data alignment
Погугли про выравнивание данных. а чтобы было 5 байт нужно

livo, выравнивание размеров полей и границы структуры. Добавляются лишние байты, грубо говоря.

По максимальному?


А смысл какой?

Alca, оптимизация по быстродействию. Меньше инструкций для доступа к полям. 


Не всегда. Если подряд идут 4 байтовых поля, или 2 двухбайтовых, то выравнивая не происходит. 

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

, где целым числом будет величина выравнивания, можно выставить единицу, а после структуры


Но опять же это для студии, не знаю, как в билдере
http://forum.sources.ru/index.php?showtopi...0&st=0&

Это сообщение отредактировал(а) null56 - 23.6.2010, 16:19

я ж написал:


Если массивом (типа char x[ 4 ]), то да, не происходит, а если в структуре (типа char a; char b; ... ) то происходит, и не по максимальному полю, а по размеру, указанному в опциях проекта или явно в коде (#pragma pack), причём у последнего приоритет.

Смотри, например такая структура

при выравнивании на 4 байта располагается в памяти след. образом:


Можешь проверить:


Это сообщение отредактировал(а) borisbn - 23.6.2010, 16:49

Вот еще по выравниванию. Может кому пригодится:
http://forum.sources.ru/index.php?showtopic=110906
http://konishchevdmitry.blogspot.com/2010/01/blog-post.html

Насколько я понял подобные директивы:

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

Почему так?

livo, в твоём примере 

делает следующее: получается указатель на структуру s и этот указатель смещается на один s вперёд.

смещается на пять s вперёд и т.д.
если хочешь "гулять по памяти, нужно получить указатель на char, а затем его инкрементировать:

borisbn, спасибо. Все понял.

  Вы бы хоть проверили перед тем как писать

sizeof(tmp) - 8 байт. 

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

Alexeis, да, действительно... ступил чуток. Вот интересно, в чём же здесь оптимизация, если я очень часто обращаюсь к tmp::b2 ?
получается, что доступ к этому полю доступ организуется примерно так (псевдо-код):

т.е. вместо одной операции (*(DWORD*)) деается две ?

  В том то и дело, что нет. Обратимся к билдеровскому дизасемблеру





Всего одна ассемблерная инструкция.

Добавлено через 6 минут и 27 секунд
borisbn, возможно оптимизация состоит только в ускорении копирования таких структур двойными словами.

Alexeis, убедил, но ведь byte ptr по логике должна быть всё равно дольше - шина данных у процессора больше 8 бит, и ему придётся маскировать данные перед выполнением byte ptr
Хотя... думаю с таким заморачиваться не только не стОит, но и вредно 

Добавлено через 3 минуты и 17 секунд
И в чём тогда преимущества выравнивания, если к любому члену можно обратиться через byte ptr или word ptr ?

А по-моему нет тут никакого выравнивания: int - 4 байта и bool - 4 байта.

Извиняюсь, был неправ. Bool - действительно 1 байт занимает.

Выравнивание данных

  Процессор, так вообще, загружает кэш линиями по 32-64 байта, но ведь если было обращение к одному полю, то велика вероятность использования и другого. С другой стороны кэш процессора должен уметь адресовать 1 байт, ведь суть ассемблера в том, что это инструкции процессора. 
  Однако все не так красиво, когда производиться копирование из 4х байтовых типов в однобайтовые и наоборот. Там действительно имеет место очистка старших регистров и всякое такое. 
  Я пытался нагуглить в чем суть оптимизации выравнивания, но толком ничего не нашел.

Суть оптимизации выравнивания в том, что при доступе в память за значением, выравненном на его размер (т.е. 4х байтовый int должен быть выровнен на 4х байтовую границу), процессор читает/пишет это значение за 1 обращение в память, если же значение не выровнено, то ему придется сделать 2 обращения в память. 

Например мы пытаемся прочесть int с адреса 0x1001: будет произведено чтение 3х байтов с 0x1001 (точнее четырех с 0x1000 и младший байт будет отброшен) и одного с адреса 0x1004, потом эти куски будут склеены.

Занимается этим специальная аппаратура в процессоре, параллельно с работой самого ядра процессора. Так что не выровненные данные замедляют работу, но менее, чем в 2 раза. 

Кстати, в современных x86 процессорах есть бит в одном из CR регистров, который отключает эту аппаратуру. При этом все не выровненные чтения и записи будут выдавать прерывания (и считаться багами   )

xvr, получается, что при извлечении одного байта, по нечетному адресу, он все равно достанет 4 байта, но уже по выравненному. В любом случае это не потребует 2х обращений к памяти для одного байтового поля (несмотря на то что адрес не кратен 4м). Получается, что оптимизация никак не связана с конвертированием байтов в слова и двойные слова и обратно.

Добавлено через 2 минуты и 40 секунд

  Этого я с лихвой накушался при работе с ARM процами. Там проверка выравнивания стоит по умолчанию. Кстати позволяет быстрее опознавать баги с затиранием указателей, поскольку вероятность записать нечетное значение в ячейку адреса велико.

Да, не потребует
Да, не связанна. Она связанна ИСКЛЮЧИТЕЛЬНО с выравниванием отдельных обращений в память, и при этом неважно - будут это поля структуры или вообще отдельные переменные в стеке или еще где то.

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


Это сообщение отредактировал(а) xvr - 24.6.2010, 13:31