hard fault на stm32f103rb при работе с указателями на uint64

[ArtDen]

Ну да, всё правильно. А как это противоречит тому, что я говорил? Я всего-лишь показал, что если компилятор сразу видит, что адрес невыровненный, то он компилирует побайтную запись. Но если как в случае с ТС, компилятор этого не знает, то генерируется оптимальный код, который падает при подаче в невыровненного указателя.

[Reflector]

Достаточно ему написать корректный пример:

Код: Выделить всё

    extern volatile uint64_t aaa;
    volatile uint64_t *ptr = (uint64_t*)(&aaa+1);
    *ptr = 0x1234567887654321;

Как будут вполне ожидаемые LDRD/STRD.

Куда в этом корректном примере запишется последний байт?

Т.е. - volatile в случае GCC никак не спасает от исключения невыровненного доступа. Не поможет оно.

Оно помогает для uint32_t*. Когда их несколько подряд, то без volatile может сгенериться STRD, но это чисто практическое наблюдение...
Вообще в случае невыровненного доступа рекомендуют memcpy использовать, она должна везде и всегда нормально работать.

[ArtDen]

[uquote="jcxz",url="/forum/viewtopic.php?p=4097480#p4097480"]Т.е. - volatile в случае GCC никак не спасает от исключения невыровненного доступа. Не поможет оно.[/uquote]

В моём случае я использовал volatile только для подавления оптимизации, чтобы гарантированно сгенерировался код записи по адресу. Без него оптимизатор всё выкинет и будет пустая программа

[astrahard]

Афигеть Вам нужно пересесть на Arduino там этот вопрос элегантно решили. Суть решения проста как я и говорил "если нельзя, но очень хочется то можно" ...

P.S. А, глубокомысленно решать вопрос как "И рыбку съесть и на-й сесть" это тупик

[Reflector]

Еще ворнинг для таких случаев можно включить: -Wcast-align

[jcxz]

[uquote="Reflector",url="/forum/viewtopic.php?p=4097508#p4097508"]

Достаточно ему написать корректный пример:

Код: Выделить всё

    extern volatile uint64_t aaa;
    volatile uint64_t *ptr = (uint64_t*)(&aaa+1);
    *ptr = 0x1234567887654321;

Как будут вполне ожидаемые LDRD/STRD.

Куда в этом корректном примере запишется последний байт?[/uquote]"Корректный", это не о том как будет исполняться, а о том чтобы соответствовало вопросу в теме. В примере ArtDen компилятор видит, что целевой объект - байтовый массив. Возможно поэтому формирует такую портянку из STRB (используя эту инфу). В моём примере у компилятора такой инфы нет, для него цель - просто некая 64-битная переменная где-то, содержимого которой он не знает.

[ArtDen]

[uquote="Reflector",url="/forum/viewtopic.php?p=4097508#p4097508"]Куда в этом корректном примере запишется последний байт?[/uquote]
Последний байт запишется корректно, потому что адрес &aaa+1 выровненный, т.к. у aaa тип uint64_t ))

Добавлено after 7 minutes 45 seconds:
[uquote="jcxz",url="/forum/viewtopic.php?p=4097537#p4097537"]В примере ArtDen компилятор видит, что целевой объект - байтовый массив. Возможно поэтому формирует такую портянку из STRB (используя эту инфу)[/uquote]
Для компилятора важна лишь инфа, достоверно невыровнен ли адрес или это неизвестно. Не важно, что именно до этого содержалось по этому указателю. Вот пример с сырыми указателями: https://gcc.godbolt.org/z/hTeGcv73v

[Reflector]

[uquote="ArtDen",url="/forum/viewtopic.php?p=4097542#p4097542"]Последний байт запишется корректно, потому что адрес &aaa+1 выровненный, т.к. у aaa тип uint64_t ))[/uquote]
Ну да, это я протупил, там же приведения нет, потому все байты запишутся непонятно куда Но изначально видимо протупил jcxz, потому что скорее всего хотел увеличить адрес именно на байт

[ArtDen]

Да вообще вопрос вроде как решённый, в том числе для ТС. Непонятно о чём тут спорить )

[jcxz]

[uquote="ArtDen",url="/forum/viewtopic.php?p=4097542#p4097542"]Последний байт запишется корректно, потому что адрес &aaa+1 выровненный, т.к. у aaa тип uint64_t ))[/uquote]
Да, конечно же там нужно: (u64 *)((char *)&aaa + 1). Ошибка.

Добавлено after 1 minute 49 seconds:
[uquote="ArtDen",url="/forum/viewtopic.php?p=4097549#p4097549"]Да вообще вопрос вроде как решённый, в том числе для ТС.[/uquote]Конечно. Пусть ставит IAR - там нет проблем.