BlackMorda, мудак (23.07.2020 16:06, просмотров: 499) ответил Гyдвин на Хм... Дело обстоит еще интереснее - если прошагать отладчиком в
окне дизассемблера, эта __aeabi_memcpy4() отрабатывает без
hardfault. LPC1768 есличо...-
- ВОТ!!! Гyдвин(1055 знак., 23.07.2020 19:10)
- Лично я не догоняю смысл одновременного использования #pragma
pack(1) и __align(4) применительно к struct {} Zoro(615 знак., 25.07.2020 16:19)
- Уже писал здесь: __align(4) просто воткнул в попытках вычислить откуда ноги растут... - Гyдвин(25.07.2020 16:26)
- ВОТ: SciFi(352 знак., 24.07.2020 10:28, ссылка)
- Приведение указателя к типу (uint8_t*) должно помочь? - VLLV(24.07.2020 10:42)
- По всем канонам должно (при #pragma pack(1)). Но пожоже компиляторостроители поимели другое видение в моем случае. - Гyдвин(24.07.2020 10:52)
- Это вряд ли. Да и написали бы, если бы так можно было. - SciFi(24.07.2020 10:47)
- Приведение указателя к типу (uint8_t*) должно помочь? - VLLV(24.07.2020 10:42)
- Aioeeeaaoiioaaie ieeooaaiieeo iaaiie! fk0(2534 знак., 23.07.2020 21:52, ссылка)
- в man memcpy написано что она принимает аргументы типа void* 3m(875 знак., 24.07.2020 08:41)
- А теперь представь, что "проверка адреса" выехала в compile time (чтоб как раз не тратить на неё время, о чём ты пишешь) и всё становится логично. Адреса в момент компиляции может и неизвестны, но их атрибуты (выравнивание) берутся из типов и известны. - fk0(24.07.2020 11:32)
- C " ВСЕГДА" не согласен (от того и пострадамши :) Выравниваю для
контроллеров, в которых это требуется - для того же MSP430. Для
ARM7TDMI тоже бы учел. Но тут, млять, Cortex M3, аффтары которого с
момента появления били себя пяткой в грудь, что поддерживается
побайтный доступ, и x86 c Паскалем на другом конце. И до каких то
пор это было без извратов - есть стандарт для memcpy() и приведения
указателей. В том же Keil v5, если использовать библиотеку
"microLIB", все пучком - Гyдвин(27 знак., 24.07.2020 09:01)
- Ещё раз -- ты работаешь не с контроллером "Cortex M3", а с некой
абстрактной моделью вычислительной машины заданной стандартом
языка. И в этой модели про невыравненный доступ сказано --
поведение неопределено. Более того, на твоём кортексе M3 оно тоже
вызывает улёт в hard fault. Поддержка побайтного доступа требует
совершенно других машинных команд (и работать всё будет в 4 раза
медленее). - fk0(24.07.2020 11:34)
- Вот и буду продолжать компилить версией 4.54 от 12 года, в которой хоть и "работать всё будет в 4 раза медленее", используя соответствующие команды, но без лишних выебонов в библиотеках. И более ранняя версия MDK ARM тоже работала корректно - правильная "абстрактная модель вычислительной машины заданная стандартом языка" (проект был запущен лет 10 назад)... - Гyдвин(24.07.2020 12:02)
- ВСЕГДА - потому что те же структуры могут переехать на другой
процессор например с M3 на M0. На M0 будет больно. - 3m(24.07.2020 10:34)
- Не переедут - зуб даю ;) В проекте 12..15 тыс. строк кода намертво
срощенного с периферией LPC17... - Гyдвин(24.07.2020 10:44)
- Звучит как профессиональные грабли.... - Evgeny_CD(24.07.2020 11:49)
- Нет, любительские... - fk0(24.07.2020 11:57)
- Звучит как профессиональные грабли.... - Evgeny_CD(24.07.2020 11:49)
- Не переедут - зуб даю ;) В проекте 12..15 тыс. строк кода намертво
срощенного с периферией LPC17... - Гyдвин(24.07.2020 10:44)
- Ещё раз -- ты работаешь не с контроллером "Cortex M3", а с некой
абстрактной моделью вычислительной машины заданной стандартом
языка. И в этой модели про невыравненный доступ сказано --
поведение неопределено. Более того, на твоём кортексе M3 оно тоже
вызывает улёт в hard fault. Поддержка побайтного доступа требует
совершенно других машинных команд (и работать всё будет в 4 раза
медленее). - fk0(24.07.2020 11:34)
- Это особенность ARM-архитектуры. При чтении/записи 32х-разрядного числа игнорируются младшие два бита адреса. Архитектура x86 без проблем может читать/писать по любому адресу. - Ale3000(24.07.2020 08:35)
- Все-таки остается одна неясность: il-2(361 знак., 24.07.2020 08:00 - 08:05)
- ИМХО, когда начинаются pragma pack и align, погромизд сам
расписался в том, что он будет во всём виноват, и стандарт не
помощник. - SciFi(24.07.2020 08:53)
- Align там не от балды - buffer[] используется для USB хоста - там
должен быть выровненный адрес для аппаратного DMA в LPC17. Align
для структуры - просто мои опыты в попытке разобраться где собака
порылась - в испытанном годами коде его нет. К pragma pack(1) тоже
нет претензий - он в моем коде для Cortex живет десяток лет и
делает свое дело - упаковывает структуру "без дырок". Для того и
добавлен в Keil. Но вот новый "шибко грамотный" компилятор, увидев
int32 в структуре и Гyдвин(243 знак., 24.07.2020 09:45)
- По какому стандарту? В ISO, ГОСТ и ANSI нет таких слов даже. - fk0(24.07.2020 11:36)
- Align там не от балды - buffer[] используется для USB хоста - там
должен быть выровненный адрес для аппаратного DMA в LPC17. Align
для структуры - просто мои опыты в попытке разобраться где собака
порылась - в испытанном годами коде его нет. К pragma pack(1) тоже
нет претензий - он в моем коде для Cortex живет десяток лет и
делает свое дело - упаковывает структуру "без дырок". Для того и
добавлен в Keil. Но вот новый "шибко грамотный" компилятор, увидев
int32 в структуре и Гyдвин(243 знак., 24.07.2020 09:45)
- Обычно функции, которая принимает в качестве параметра указатель void * (как в memcpy) можно передать указатель любого типа. Значит - (void *) гарантированно не выравненный. - il-2(24.07.2020 08:03)
- ИМХО, когда начинаются pragma pack и align, погромизд сам
расписался в том, что он будет во всём виноват, и стандарт не
помощник. - SciFi(24.07.2020 08:53)
- Речи правильные толкаешь :) Но компилятор, которому явно привели
тип указателя, но он "вызывает оптимизированную функцию которая
быстро копирует 32-битными словами" не имеет права на жизнь ;) - Гyдвин(23.07.2020 22:13)
- Почему "явное приведение типа указателя" считается каким-то
значимым аргументом? Всё равно перед вызовом memcpy эти указатели
неявно приведутся к void*. С тем же успехом можно в спортлото
написать. - SciFi(24.07.2020 09:57)
- Я тоже так считал и считаю :) Но из библиотеки вызывается другая
функция в memcpy() (см. первый пост), которую я совсем не просил.
Оттого и нежданчик... - Гyдвин(24.07.2020 10:09)
- А оптимизация как-то влияет? - VLLV(24.07.2020 11:57)
- нет. - Гyдвин(24.07.2020 12:03)
- А оптимизация как-то влияет? - VLLV(24.07.2020 11:57)
- Я тоже так считал и считаю :) Но из библиотеки вызывается другая
функция в memcpy() (см. первый пост), которую я совсем не просил.
Оттого и нежданчик... - Гyдвин(24.07.2020 10:09)
- gcc "чудный и замечательный" компилятор Zoro(183 знак., 24.07.2020 00:39)
- Проблема в том, что у тебя в программе _нет_ такого типа (U32, но
только "упакованный"). Если его руками создать, как в примере по
ссылке (внутри IY) -- то оно даже будет как надо работать.
Упакованные структуры это очень неполноценное и нестандартная
надстройка над C/C++. Не продуманная. Костыль. Её неспроста нет в
стандарте. Она "недоделанная" и не совсместима с моделью памяти и
системой типов C/C++. Стандартными (для C++, не для C) средствами
можно изголиться и сделать fk0(552 знак., 23.07.2020 22:28)
- Нет уж... Тысячи строк кода, драйверы, куски стороннего кода (та же
FatFs) и пр. как то не способствуют выворачиванию всего наизнанку.
А по этому топику: Cortex M3 (LPC17) имеет аппаратную побайтную
адресацию, посему фтопку компилер, взомнивший себя шибко
грамотным... Более ранняя версия работала "как в мудрых книгах
написано" - привели указатель к void* или char*, вызывается
предсказуемая библиотечная функция побайтного копирования (и все
остальные из string.h). И Гyдвин(118 знак., 23.07.2020 23:39)
- Говнокода. И не такие уж и тысячи. Практически всё что завелось не
на x86 такого говнокода не содержит. Потому, что и MIPS, и ARM --
это аппаратное исключение при невыравненном обращении и дальше либо
фиксация ошибки, либо программная эмуляция команды с невыравненным
чтением-записью (очень не быстро...) И даже на современном x86
словить исключение при невыравненном обращении -- запросто
(векторные инструкции). Ещё раз, повторю, упакованные структуры --
НЕ СТАНДАРТНАЯ ХЕРНЯ. fk0(3121 знак., 24.07.2020 01:19, ссылка)
- Все же тут похоже на глюк компилятора. PACKED это такой же
модификатор структуры как volatile или const которые должны
распространяться на все члены структуры. Соответственно, когда
делается &a.b на выходе должен получаться указатель с
соответствующим модификатором. А тут модификатор PACKED потерялся,
остальное последствия. Но я не большой знаток. - AlexBi(24.07.2020 09:53)
- А какой тип будут иметь по-твоему тогда члены структуры? Если в
структуры положить структуры и их тоже сделать packed -- получится.
А если в структуре уже лежит обычный int? Явно ж записано, что
такое-то поле -- int и с ним могут что-то делать и нельзя неявно
подменить тип -- работать перестанет (программист может начать
где-то сравнивать типы, например). Сама идея упакованных структур
-- не продуманная, в ней есть логические противоречия. - fk0(24.07.2020 11:46)
- В данном случае члены структуры должны становиться packed. А как,
по-твоему, работает (должно работать) volatile структура? Будут ее
члены каждый раз перечитываться? Указатель на члена структуры будет
volatile? AlexBi(405 знак., 24.07.2020 13:50)
- С чего ты решил, что они кому-то что-то должны? Где это написано? Тип поля, если это не вновь определяемая на месте структура, уже определён ранее и измениться никак не может (иначе это другой, новый тип должен быть). А выравнивание и размер -- это атрибуты, свойства, типа. Поэтому если ты в упакованную структуру положишь ранее определённый тип, то он сохранит свои свойства. Структура останется с "дырками" для выравнивания, обычный int сохранится с alignas(4). Что мы и fk0(263 знак., 24.07.2020 14:34, ссылка)
- В данном случае члены структуры должны становиться packed. А как,
по-твоему, работает (должно работать) volatile структура? Будут ее
члены каждый раз перечитываться? Указатель на члена структуры будет
volatile? AlexBi(405 знак., 24.07.2020 13:50)
- В студии не хватает кода. Там запросто может быть два определения
структуры -- с packed и без. - SciFi(24.07.2020 09:59)
- Вот суть: Гyдвин(1541 знак., 24.07.2020 10:24)
- А если собрать демо пример чисто в одном файле ? Zoro(333 знак., 25.07.2020 16:42)
- Интересно, а как работает банальное чтение невыравненного U32 из структуры? - VLLV(24.07.2020 12:02)
- Косяк -- это твой говнокод. Даже комментарии на русском языке не
осилил. А поведение результат работы оптимизатора, который считает,
что тип int (U32 -- самодельные типы -- 100% говнокод) никак не
может лежать по невыравненному адресу. Ты можешь в структуру
положить другие packed структуры и тогда оно заработает нормально. - fk0(24.07.2020 11:50)
- Комментарии - твои проблемы, да и не важны они в этой теме. До v5
оптимизатор ARMCC считал, что все пучком касаемо Cortex M3 - все
может лежать там, куда положили. И делал то, что указали конкретно.
"Самодельные типы" "придуманы" не мной, а самим Keil. Так шта без
эмоций... Гyдвин(1329 знак., 24.07.2020 12:21)
- Пиши дальше на нестандартных языках и собирай нестандартные
грабли... - fk0(24.07.2020 12:27)
- Кхе-кхе... Кто-то говорил, что граблей нет. - VLLV(24.07.2020 12:47)
- Нормальный, кросс-платформенный код, написанный на стандартизированном подмножестве языка, таких проблем не имеет и работает на любой платформе сразу. - fk0(24.07.2020 12:53)
- Дык и спитч был как раз о "нестандартном" языке от ARM и его
библиотеках (RTL, например), о куче написанного кода, прекрасно
работавшего с ранними компиляторами, о конкретном чипе Cortex M3 -
LPC17 ;) А свою напыщенность можешь затолкать себе в жопу вместе с
апплобом. Меня - ЛЮБИТЕЛЯ оно нисколько не колышет :) - Гyдвин(24.07.2020 12:40)
- Спиши код у SciFi: - fk0(24.07.2020 12:51, ссылка)
- Кхе-кхе... Кто-то говорил, что граблей нет. - VLLV(24.07.2020 12:47)
- Пиши дальше на нестандартных языках и собирай нестандартные
грабли... - fk0(24.07.2020 12:27)
- нет "самодельных типов", они все восходят к оригинальным. uint32_t
ничем не отличается от U32 - VLLV(24.07.2020 12:00)
- Вот я смотрю на твой код и как я пойму, что U32 это unsigned int на ARM? А что я буду делать на 16-битной машине (где U32 будет излишне неэффективен). Смысл использования стандартных типов и функций в том, что не надо каждый раз гадать -- а это это такое (может у тебя там написано, мол typedef unsigned short U32), текст читается любым программистом. А вот зачем придумывать нестандартные "алиасы" к стандартным типам и функциям, чтоб человек со стороны прочитать не мог? - fk0(24.07.2020 12:11)
- Комментарии - твои проблемы, да и не важны они в этой теме. До v5
оптимизатор ARMCC считал, что все пучком касаемо Cortex M3 - все
может лежать там, куда положили. И делал то, что указали конкретно.
"Самодельные типы" "придуманы" не мной, а самим Keil. Так шта без
эмоций... Гyдвин(1329 знак., 24.07.2020 12:21)
- Вот суть: Гyдвин(1541 знак., 24.07.2020 10:24)
- А какой тип будут иметь по-твоему тогда члены структуры? Если в
структуры положить структуры и их тоже сделать packed -- получится.
А если в структуре уже лежит обычный int? Явно ж записано, что
такое-то поле -- int и с ним могут что-то делать и нельзя неявно
подменить тип -- работать перестанет (программист может начать
где-то сравнивать типы, например). Сама идея упакованных структур
-- не продуманная, в ней есть логические противоречия. - fk0(24.07.2020 11:46)
- Все же тут похоже на глюк компилятора. PACKED это такой же
модификатор структуры как volatile или const которые должны
распространяться на все члены структуры. Соответственно, когда
делается &a.b на выходе должен получаться указатель с
соответствующим модификатором. А тут модификатор PACKED потерялся,
остальное последствия. Но я не большой знаток. - AlexBi(24.07.2020 09:53)
- Говнокода. И не такие уж и тысячи. Практически всё что завелось не
на x86 такого говнокода не содержит. Потому, что и MIPS, и ARM --
это аппаратное исключение при невыравненном обращении и дальше либо
фиксация ошибки, либо программная эмуляция команды с невыравненным
чтением-записью (очень не быстро...) И даже на современном x86
словить исключение при невыравненном обращении -- запросто
(векторные инструкции). Ещё раз, повторю, упакованные структуры --
НЕ СТАНДАРТНАЯ ХЕРНЯ. fk0(3121 знак., 24.07.2020 01:19, ссылка)
- Нет уж... Тысячи строк кода, драйверы, куски стороннего кода (та же
FatFs) и пр. как то не способствуют выворачиванию всего наизнанку.
А по этому топику: Cortex M3 (LPC17) имеет аппаратную побайтную
адресацию, посему фтопку компилер, взомнивший себя шибко
грамотным... Более ранняя версия работала "как в мудрых книгах
написано" - привели указатель к void* или char*, вызывается
предсказуемая библиотечная функция побайтного копирования (и все
остальные из string.h). И Гyдвин(118 знак., 23.07.2020 23:39)
- Почему "явное приведение типа указателя" считается каким-то
значимым аргументом? Всё равно перед вызовом memcpy эти указатели
неявно приведутся к void*. С тем же успехом можно в спортлото
написать. - SciFi(24.07.2020 09:57)
- тут знаю одно - атрибуты packed и volatile при пропускании через формальные параметры функции завсегда теряются, но по ходу успевают цепляться яйцами:) Vit(147 знак., 23.07.2020 22:12)
- Да и ты сделал #pragma pack, но нихера не вернул обратно (через pragma push/pop -- смотри у меня пример по ссылке). В итоге у тебя вся программа "упакованная" и глючная. Хуже того, в зависимости от порядка включения хедеров одни и те же структуры в разных модулях могли оказаться упакованные или нет. Кровь, кешки, фарш! - fk0(23.07.2020 21:55)
- в man memcpy написано что она принимает аргументы типа void* 3m(875 знак., 24.07.2020 08:41)
- Лично я не догоняю смысл одновременного использования #pragma
pack(1) и __align(4) применительно к struct {} Zoro(615 знак., 25.07.2020 16:19)
- Нужно весь тип структуры смотреть - пакед, не пакед, что впереди,
размерность. - VLLV(23.07.2020 16:29)
- Да вроде как memcpy() обязана побайтно копировать, имея на входе 2
указателя... Кстати, вместо (void *) пробовал (char *). Тут дело в
чем то другом - если эту __aeabi_memcpy4() пройти пошагово в
отладчике, все пучком - не вылетает... чЮдеса... - Гyдвин(23.07.2020 16:37)
- 1. Вроде как зависит от реализации, а в реализации могут быть косяки. 2. При пошаговом выполнении в прерывания не заходит. - VLLV(23.07.2020 16:47)
- замечал много раз в отладчике по шагам даже явные косяки и не попадаешь в hardfault ! а в работе залетает - Aleksey_75(23.07.2020 16:41)
- Да вроде как memcpy() обязана побайтно копировать, имея на входе 2
указателя... Кстати, вместо (void *) пробовал (char *). Тут дело в
чем то другом - если эту __aeabi_memcpy4() пройти пошагово в
отладчике, все пучком - не вылетает... чЮдеса... - Гyдвин(23.07.2020 16:37)
- ВОТ!!! Гyдвин(1055 знак., 23.07.2020 19:10)