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

ArtDen

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

Реклама

Reflector

jcxz писал(а):

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

Код:

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

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

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

jcxz писал(а):

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

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

Реклама

ArtDen

jcxz писал(а):

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

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

astrahard

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

...

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

Реклама

Эиком - электронные компоненты и радиодетали

Reflector

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

Реклама

jcxz

Reflector писал(а):

jcxz писал(а):

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

Код:

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

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

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

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

Реклама

ArtDen

Reflector писал(а):

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

Последний байт запишется корректно, потому что адрес &aaa+1 выровненный, т.к. у aaa тип uint64_t ))

Добавлено after 7 minutes 45 seconds:

jcxz писал(а):

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

Для компилятора важна лишь инфа, достоверно невыровнен ли адрес или это неизвестно. Не важно, что именно до этого содержалось по этому указателю. Вот пример с сырыми указателями: https://gcc.godbolt.org/z/hTeGcv73v

Reflector

ArtDen писал(а):

Последний байт запишется корректно, потому что адрес &aaa+1 выровненный, т.к. у aaa тип uint64_t ))

Ну да, это я протупил, там же приведения нет, потому все байты запишутся непонятно куда

Но изначально видимо протупил jcxz, потому что скорее всего хотел увеличить адрес именно на байт

ArtDen

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

Реклама

jcxz

ArtDen писал(а):

Последний байт запишется корректно, потому что адрес &aaa+1 выровненный, т.к. у aaa тип uint64_t ))

Да, конечно же там нужно: (u64 *)((char *)&aaa + 1). Ошибка.

Добавлено after 1 minute 49 seconds:

ArtDen писал(а):

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

Конечно. Пусть ставит IAR - там нет проблем. :)))

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

Кто сейчас на форуме