-
- Вклинюсь тут со своими шурушками. Звepoящep(465 знак., 05.05.2020 17:46)
- Зачем здесь юнион? Мое имхо union нужен если в одну область памяти
нужно разместить несколько объектов разных типов abivan(327 знак., 06.05.2020 15:17)
- Я ради наглядности использую юнион, эти указатели с индексами ...
банально мозг херней занят, звезды ловит. - VLLV(06.05.2020 16:13)
- это дело привычки. Привыкнешь и будешь считать что так и надо. это
из той же серии кто то считает, что сравнение с нулем повышает
наглядность кода abivan(439 знак., 06.05.2020 16:53)
- Чота я не понял, зачем там packed. Да и вообще, зачем это всё. Угар
кокойты. - SciFi(06.05.2020 16:55)
- Вот поэтому некоторым и нельзя goto. - fk0(06.05.2020 18:27)
- Во всех учебниках описывают битовые поля просто через unsigned,
студенты evgeniy1294(12 знак., 06.05.2020 19:27, ссылка)
- Вот поэтому долбоёбам и запрещают goto. Packed тоже нужно запретить, другого варианта видимо уж нет. fk0(4 знак., 06.05.2020 19:41, ссылка)
- :) - Vit(06.05.2020 19:37)
- Во всех учебниках описывают битовые поля просто через unsigned,
студенты evgeniy1294(12 знак., 06.05.2020 19:27, ссылка)
- Вот поэтому некоторым и нельзя goto. - fk0(06.05.2020 18:27)
- Чота я не понял, зачем там packed. Да и вообще, зачем это всё. Угар
кокойты. - SciFi(06.05.2020 16:55)
- это дело привычки. Привыкнешь и будешь считать что так и надо. это
из той же серии кто то считает, что сравнение с нулем повышает
наглядность кода abivan(439 знак., 06.05.2020 16:53)
- Я ради наглядности использую юнион, эти указатели с индексами ...
банально мозг херней занят, звезды ловит. - VLLV(06.05.2020 16:13)
- Что мешает сделать "UCHAR Map[1]"? - SciFi(05.05.2020 18:06)
- Это-то можно, но это не решает проблемы :) Вот суну я такой массив
в УАРТ, и какую длину указывать? - Звepoящep(05.05.2020 18:13)
- sizeof(StorageDataMap), какой же ещё? - SciFi(05.05.2020 18:17)
- Ну, блин. Сдаюсь :) - Звepoящep(05.05.2020 18:31)
- sizeof(StorageDataMap), какой же ещё? - SciFi(05.05.2020 18:17)
- Это-то можно, но это не решает проблемы :) Вот суну я такой массив
в УАРТ, и какую длину указывать? - Звepoящep(05.05.2020 18:13)
- Объявить typedef struct{} FieldNameStruct отдельно, чуть выше и
Map[sizeof(FieldNameStruct)] - Cкpипaч(05.05.2020 17:55)
- О! Что-то не подумал. Только наверно надо
Map[sizeof(FieldNameStruct) / sizeof(UCHAR)] - Звepoящep(05.05.2020 18:16)
- sizeof(UCHAR) -- это сильно. Заодно надо бы проверить, что 1==1. - SciFi(05.05.2020 18:20)
- А вдруг UCHAR != unsigned char? LightElf(1 знак., 05.05.2020 21:54, картинка)
- Зато переносимость :) И, эта, у вас magic numbers...нехорошо 8) - Cкpипaч(05.05.2020 18:25)
- sizeof(char) вообще везде равен 1. Даже у TMS320 - lloyd(05.05.2020 18:32)
- Ага. В писюках int - 32 бита :) - Звepoящep(05.05.2020 18:27)
- sizeof(UCHAR) -- это сильно. Заодно надо бы проверить, что 1==1. - SciFi(05.05.2020 18:20)
- О! Что-то не подумал. Только наверно надо
Map[sizeof(FieldNameStruct) / sizeof(UCHAR)] - Звepoящep(05.05.2020 18:16)
- Зачем здесь юнион? Мое имхо union нужен если в одну область памяти
нужно разместить несколько объектов разных типов abivan(327 знак., 06.05.2020 15:17)
- В документации на stm32h750vb Figure 3. STM32H750xB bus matrix BlackMorda(48 знак., 05.05.2020 11:10)
- Выравнивание на N это размещение данных или кода по адресам кратным
N. Это производится а) для скорости, потому что невыравненные
данные/код требуют больше циклов чтения шины. Для ускорения доступа
собственно ядра, и для ускорения пред-загрузки линии кэша. б)
некоторые RISC архитектуры не способны читать память по
невыравненным адресам вообще, т.е. в них "ячейками памяти"
считаются WORD'ы размером в ширину шины - 2 или 4 или даже 8 байт.
Hardware unaligned acccess появился RxTx(198 знак., 30.04.2020 18:47)
- Вы нам пересказали букварь. Теперь перескажите зачем стек (в первую
очередь), структуры и функции на "толстых" процессорах включая arm
размещают с выравниванием в разы превышающим разрядность процессора
например 8, 16 или даже 64 байта тогда как для 32-х битного
процессора достаточно выравнивания 4 байта. - 3m(30.04.2020 19:17)
- Я не "нам" и не "пересказывал", у вас путаница по пьянке случилась.
:))) Я отвечал на заданный вопрос конкретному человеку -
топикстартеру. Чаще всего первейшая причина выравнивания больше чем
ширина шины - align на линию кэша кода/данных. Затем идут регистры
шире чем регистры ядра, например double и ALIGN 8. И наконец,
специфичные случаи - выравнивание на страницы TLB и проч
вспомогательные структуры и дескрипторы. Выше я забыл еще один
важный случай - DMA-engine может RxTx(552 знак., 30.04.2020 20:09)
- Спасибо. Просто я барахтаюсь не выше CM4, не ожидал что нечаянно
забрел в высшую лигу :) - VLLV(30.04.2020 21:48)
- Реальность как обычно, смешнее :)) В призрачном прошлом пришлось
шатать RISCовые процы, ну и разумеется Intel/Amd. Недавно так
повернулось что dsPIC'и (которые тоже unaligned access не делают),
а вот за свежие ARM взялся совсем недавно, так что барахтаюсь я
тоже там :)) Я вот что забыл сказать. У тебя большие структуры?
Попробуй переставлять внутренние поля. Иногда можно при не-потере
скорости сделать структуру компактнее. И есть еще нюанс. При
вычитке массива из структур RxTx(240 знак., 30.04.2020 22:09)
- Конечно, поля сортировал, чтобы уменьшить дыры. Сейчас над проектом
работают в основном другие, нужно перепроверить. Компилятор не
любит вложенные упакованные структуры, дает предупреждение о
невыровненном доступе, хотя по идее компилятор обязан обеспечить и
невыровненный доступ. - VLLV(30.04.2020 22:45)
- Недавно тему обмусоливали: с полями в упакованных структурах
невозможно работать через указатель, это поле усеянное граблями. - fk0(30.04.2020 23:13)
- А зачем структуры паковать? В АРМах места мало? :) - Звepoящep(05.05.2020 12:53)
- Банальные данные в EEPROM. - VLLV(05.05.2020 16:05)
- Зазиповал, сохранил в ЕЕПРОМ. Считал из ЕЕПРОМ, раззиповал, структуры забил :) - Звepoящep(05.05.2020 17:29)
- Я предпочитаю сортировать поля, чтобы между ними было поменьше дыр. Да и дыры сами по себе редко мешают, чаще это суеверие, КМК. - SciFi(05.05.2020 16:09)
- От дурости... - fk0(05.05.2020 13:49)
- Банальные данные в EEPROM. - VLLV(05.05.2020 16:05)
- Угу, забываю. Но прямое обращение компилятор должен поддержать? - VLLV(30.04.2020 23:46)
- Без кода нещитово. - SciFi(30.04.2020 23:48)
- Кортексам специальный код не нужен, а для arm7, у которого
невыровненное обращение к памяти вызывает bus fault, ИАР вставляет
вызов функции __aeabi_uread4, которая читает побайтно, ну или
__aeabi_uwrite4 для записи. йцyкeн(2172 знак., 01.05.2020 00:47)
- Я хотел сказать "код в студию". - SciFi(01.05.2020 08:54)
- Кортексам специальный код не нужен, а для arm7, у которого
невыровненное обращение к памяти вызывает bus fault, ИАР вставляет
вызов функции __aeabi_uread4, которая читает побайтно, ну или
__aeabi_uwrite4 для записи. йцyкeн(2172 знак., 01.05.2020 00:47)
- Без кода нещитово. - SciFi(30.04.2020 23:48)
- А зачем структуры паковать? В АРМах места мало? :) - Звepoящep(05.05.2020 12:53)
- Недавно тему обмусоливали: с полями в упакованных структурах
невозможно работать через указатель, это поле усеянное граблями. - fk0(30.04.2020 23:13)
- Конечно, поля сортировал, чтобы уменьшить дыры. Сейчас над проектом
работают в основном другие, нужно перепроверить. Компилятор не
любит вложенные упакованные структуры, дает предупреждение о
невыровненном доступе, хотя по идее компилятор обязан обеспечить и
невыровненный доступ. - VLLV(30.04.2020 22:45)
- Какая такая лига? Просто пижонство. Кстати, у многих STM32 шина
флеша имеет ширину 64 или 128 разрядов, там выравнивание точек
входа в функции с такой кратностью может быть обосновано. - SciFi(30.04.2020 22:01)
- Не вижу связи ширины флэш с данными, мои данные в ЕЕПРОМ и внешней
Flash, еще будем выравнивать по длине сектора SPI flash? - VLLV(30.04.2020 22:40)
- Это я просто для поддержания разговора, просьба не беспокоиться :-) - SciFi(30.04.2020 22:41)
- :) проверка бдительности, ага... - VLLV(30.04.2020 22:46)
- Это я просто для поддержания разговора, просьба не беспокоиться :-) - SciFi(30.04.2020 22:41)
- Не вижу связи ширины флэш с данными, мои данные в ЕЕПРОМ и внешней
Flash, еще будем выравнивать по длине сектора SPI flash? - VLLV(30.04.2020 22:40)
- Реальность как обычно, смешнее :)) В призрачном прошлом пришлось
шатать RISCовые процы, ну и разумеется Intel/Amd. Недавно так
повернулось что dsPIC'и (которые тоже unaligned access не делают),
а вот за свежие ARM взялся совсем недавно, так что барахтаюсь я
тоже там :)) Я вот что забыл сказать. У тебя большие структуры?
Попробуй переставлять внутренние поля. Иногда можно при не-потере
скорости сделать структуру компактнее. И есть еще нюанс. При
вычитке массива из структур RxTx(240 знак., 30.04.2020 22:09)
- Спасибо. Просто я барахтаюсь не выше CM4, не ожидал что нечаянно
забрел в высшую лигу :) - VLLV(30.04.2020 21:48)
- cache line? - йцyкeн(30.04.2020 19:27)
- Я не "нам" и не "пересказывал", у вас путаница по пьянке случилась.
:))) Я отвечал на заданный вопрос конкретному человеку -
топикстартеру. Чаще всего первейшая причина выравнивания больше чем
ширина шины - align на линию кэша кода/данных. Затем идут регистры
шире чем регистры ядра, например double и ALIGN 8. И наконец,
специфичные случаи - выравнивание на страницы TLB и проч
вспомогательные структуры и дескрипторы. Выше я забыл еще один
важный случай - DMA-engine может RxTx(552 знак., 30.04.2020 20:09)
- Вы нам пересказали букварь. Теперь перескажите зачем стек (в первую
очередь), структуры и функции на "толстых" процессорах включая arm
размещают с выравниванием в разы превышающим разрядность процессора
например 8, 16 или даже 64 байта тогда как для 32-х битного
процессора достаточно выравнивания 4 байта. - 3m(30.04.2020 19:17)
- Во! Вот и у меня была проблема, решил ее чужим способом. Как - сам
не знаю. Но замечательно работает. Вот чего я такого сделал??? Лaгyнoв(677 знак., 30.04.2020 18:17)
- Пиздец говнокод. Нужно просто сложить в один union твой буфер и
тип, по которому ты хочешь выравнивать. Тот же int. - fk0(30.04.2020 18:29)
- Этот "говнокод" - выборочная копипаста из stm32f7xx_hal_def.h - RxTx(30.04.2020 20:15)
- два года назад меня это сильно донимало. Ну не программист я! А у меня при записи в файл на USB Flash из буфера BUFDISK при его размере 511 байт и меньше было всё нормально, и при бОльшем размере - нулевой файл. Зато теперь при любом размере всё хорошо. :-) - Лaгyнoв(30.04.2020 19:39)
- Если ALIGN кто-то уже перезадал выше, например во включачемых файлах, будет ли: "тип по которому хочешь выравнять, тот же int" выравниваться по желаемой границе? - RxTx(30.04.2020 19:07)
- Пиздец говнокод. Нужно просто сложить в один union твой буфер и
тип, по которому ты хочешь выравнивать. Тот же int. - fk0(30.04.2020 18:29)
- Что значит "всё выравнивание"? Выравнивание каждого типа данных
зависит от его alignas свойства. У всех разное. Если речь про
new/malloc -- потому, что таков BIGGEST_ALIGNMENT (который
применяется, когда тип не пойми какой). Например, из-за векторных
значений для FPU, или просто потому, что в ABI так прописано. fk0(104 знак., 30.04.2020 17:38)
- Я пользуюсь профессиональным компилятором известной скандинавской
фирмы, там пишут только про 4 байта. - VLLV(30.04.2020 17:54)
- У меня до 4 округляет. йцyкeн(476 знак., 30.04.2020 18:14)
- напишите что получится если объявить структуру так: 3m(121 знак., 30.04.2020 19:16)
- Как и следовало ожидать, размер 12, смещение 8 и 9 йцyкeн(1367 знак., 30.04.2020 19:25)
- Контроллер? Не все ARM одинаково полезны, похоже. - VLLV(30.04.2020 18:18)
- Надо в структуру вставить long long, будет другая картина. - SciFi(30.04.2020 18:19)
- Да, с int64_t округляет до 8. - йцyкeн(30.04.2020 19:43)
- Надо в структуру вставить long long, будет другая картина. - SciFi(30.04.2020 18:19)
- напишите что получится если объявить структуру так: 3m(121 знак., 30.04.2020 19:16)
- Шведы должны ссылаться на ARM EABI, и уже там будет написано про 8
байт. Читайте мелкий шрифт и/или нанимайте йуристов. - SciFi(30.04.2020 18:13)
- Да, как бы мне адвокатов не пришлось нанимать ... По лезвию ножа хожу :) - VLLV(30.04.2020 18:23)
- У меня до 4 округляет. йцyкeн(476 знак., 30.04.2020 18:14)
- Я пользуюсь профессиональным компилятором известной скандинавской
фирмы, там пишут только про 4 байта. - VLLV(30.04.2020 17:54)
- если 32 бита разделить на 8 байт, получается в байте 4 бита...
может все таки "выравнивание происходит по границе 4 байт". А по
существу выравнивание - опция компилятора. - IBAH(30.04.2020 17:28)
- Это я напомнил ширину ARM, может кто не знает :) - VLLV(30.04.2020 17:45)
- для начала структуру покажи - abivan(30.04.2020 17:17)
- Показываю. Последнее поле в структуре 1 байт, расположен со
смещением 5170-49d0 = 7a0 = 1952. Какой должен быть размер
структуры? 1956, логично? А вот ни хрена, 1960. VLLV(1 знак., 30.04.2020 17:45, картинка)
- Размер структуры растягивается до значения его alignas которое
определяется всеми полями в совокупности. Это нужно, чтоб можно
было адресовать массивы структур как v[i] = (char*)v +
i*sizeof(struct). Если бы у тебя sizeof() давал честный размер, то
как бы ты работал с массивами? fk0(70 знак., 30.04.2020 18:18, ссылка)
- Не, эта теория понятна, я больше недоумеваю, почему выравнивание
стало 8 вместо 4. - VLLV(30.04.2020 18:21)
- Потому, что внутри твоих вложенных структур нашлось что-то, чему нужно выравнивание на 8 байт. - fk0(30.04.2020 18:30)
- Не, эта теория понятна, я больше недоумеваю, почему выравнивание
стало 8 вместо 4. - VLLV(30.04.2020 18:21)
- Если в структуре есть 64-разрядное поле, то она вся должна иметь
такое выравнивание. Ну и размер, кратный 8 байтам. Одна из причин
для такого размера -- массив структур. - SciFi(30.04.2020 18:02)
- 1. С какого перепуга, если ядро не читает 8 байт за раз, а только 4
байта? 2. Не очень понятен процесс компиляции, в одном файле с этим
типом нет массива структур, в другом есть массив структур - как они
договариваются? - VLLV(30.04.2020 18:09)
- А какая связь вообще с байтами? Ты знаешь как оно внутри работает?
Может найтись масса неочевидных причин, почему иметь "некруглые"
адреса сложно. Пусть и читает по 4 байта за раз, но чтоб по 4 байта
считать длинное значение, long long, long double, вектор, и
обработать его последоательно нужно уметь вычитывать его отдельные
части. И куда проще это делать с выравненного адреса -- потому, что
достаточно правильным образом замаскировать младшие биты адреса, а
с fk0(723 знак., 30.04.2020 18:26)
- Убедил. Навскидку потери памяти с таким выравниванием не сильно
большие, должно жить. - VLLV(30.04.2020 18:35)
- В спортивном программировании вместо массивов структур лучше
"транспонировать" их в разнотипные массивы данных: во-первых места
займёт меньше, во-вторых адресация данных в коде станет более
эффективной. Пример: fk0(573 знак., 30.04.2020 18:47)
- Компромиссы в структурировании (а следовательно, и строгой типизации) недопустимы, товарищ ! - VLLV(30.04.2020 21:59)
- Может дать эффект только если полей мало. Иначе окажется что в процессоре ry и rz, подходящих для такой адресации очень мало, и для работы с одним элементом из массива потребуется частая перегрузка ry и rz. - AlexBi(30.04.2020 19:02)
- В спортивном программировании вместо массивов структур лучше
"транспонировать" их в разнотипные массивы данных: во-первых места
займёт меньше, во-вторых адресация данных в коде станет более
эффективной. Пример: fk0(573 знак., 30.04.2020 18:47)
- Убедил. Навскидку потери памяти с таким выравниванием не сильно
большие, должно жить. - VLLV(30.04.2020 18:35)
- Вроде бы в EABI такое записали. Иногда ссылаются на LDRD, STRD.
Можно ещё сослаться на Cortex-M7 и 64-разрядную шину AXI. В общем,
при желании причины найдутся. - SciFi(30.04.2020 18:09)
- Спасибо, начинает проясняться. In ARMv5TE, or in ARMv6 when SCTLR.U is 0, LDRD and STRD doubleword data transfers must be eight-byte aligned. Правда, у меня всего лишь STM32L4, а он CM4, правда есть FPU. - VLLV(30.04.2020 18:16)
- А какая связь вообще с байтами? Ты знаешь как оно внутри работает?
Может найтись масса неочевидных причин, почему иметь "некруглые"
адреса сложно. Пусть и читает по 4 байта за раз, но чтоб по 4 байта
считать длинное значение, long long, long double, вектор, и
обработать его последоательно нужно уметь вычитывать его отдельные
части. И куда проще это делать с выравненного адреса -- потому, что
достаточно правильным образом замаскировать младшие биты адреса, а
с fk0(723 знак., 30.04.2020 18:26)
- 1. С какого перепуга, если ядро не читает 8 байт за раз, а только 4
байта? 2. Не очень понятен процесс компиляции, в одном файле с этим
типом нет массива структур, в другом есть массив структур - как они
договариваются? - VLLV(30.04.2020 18:09)
- uint64_t в структуре есть? - abivan(30.04.2020 18:02)
- С ходу не вижу, хз, там столько вложений структур. Почему это должно влиять? - VLLV(30.04.2020 18:07)
- Размер структуры растягивается до значения его alignas которое
определяется всеми полями в совокупности. Это нужно, чтоб можно
было адресовать массивы структур как v[i] = (char*)v +
i*sizeof(struct). Если бы у тебя sizeof() давал честный размер, то
как бы ты работал с массивами? fk0(70 знак., 30.04.2020 18:18, ссылка)
- Показываю. Последнее поле в структуре 1 байт, расположен со
смещением 5170-49d0 = 7a0 = 1952. Какой должен быть размер
структуры? 1956, логично? А вот ни хрена, 1960. VLLV(1 знак., 30.04.2020 17:45, картинка)
- Подробности не помешали бы. - SciFi(30.04.2020 17:16)
- Вклинюсь тут со своими шурушками. Звepoящep(465 знак., 05.05.2020 17:46)