caxapa.ru :: Речи правильные толкаешь :) Но компилятор, которому явно привели тип указателя, но он "вызывает оптимизированную функцию которая быстро копирует 32-битными словами" не имеет права на жизнь ;)

Почему "явное приведение типа указателя" считается каким-то значимым аргументом? Всё равно перед вызовом 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)

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 и без. - 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)
        
        Через 4 команды LDRB и три команды EOR собирается целов слово в регистре? Регистровевому аллокатору нужно соответственно один лишний свободный регистр, которых у арма всего-то 3-4 штуки (остальные надо сохранять перед использованием). - fk0(24.07.2020 12:06)
        
        Косяк -- это твой говнокод. Даже комментарии на русском языке не осилил. А поведение результат работы оптимизатора, который считает, что тип 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)
        
        А если этого не требуется от слова вообще? Если и нужны RTL ARM + всяческие удобства, предоставляемые cредой Keil конкретно, например, для того же LPC17. И еще - расскажи про кросс-платформенность пользователям Кубо-STM32... - Гyдвин(24.07.2020 13:16)
        
        У тебя проблема уже есть, несмотря на то, что "не нужно". Причём до тебя похоже не доходит, что проблема куда шире... (чем не работающий memcpy). fk0(2639 знак., 24.07.2020 14:03, ссылка, ссылка)
        
        Дык и спитч был как раз о "нестандартном" языке от ARM и его библиотеках (RTL, например), о куче написанного кода, прекрасно работавшего с ранними компиляторами, о конкретном чипе Cortex M3 - LPC17 ;) А свою напыщенность можешь затолкать себе в жопу вместе с апплобом. Меня - ЛЮБИТЕЛЯ оно нисколько не колышет :) - Гyдвин(24.07.2020 12:40)
        
        Спиши код у SciFi: - fk0(24.07.2020 12:51, ссылка)
        
        нет "самодельных типов", они все восходят к оригинальным. 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)

ARM, RISC-V контроллеры