[repstosw 18]

 

11 minutes ago, one_eight_seven said:

++not_necessary_aligned; // 0x30000001

 

Ну так здесь программист - идиот.   Мы говорили про компилятор вообще-то.  А вы с jcxz упорно   продолжаете фабриковать  примеры, где  программист намеряно допустил передачу невыровненного указателя.

[one_eight_seven 6]

6 minutes ago, VladislavS said:

Вестимо несколькими чтениями.

Ну или burst-доступом. Это уже моя профдеформация - я имел в виду, что не знаю какие именно параметры шинного доступа будут исопльзоваться. Но вы правильно написали - для кода это должно быть прозрачно.

 

5 minutes ago, __inline__ said:

Ну так здесь программист - идиот.   Мы говорили про компилятор вообще-то.  А вы с jcxz упорно   продолжаете фабриковать  примеры, где  программист намеряно допустил передачу невыровненного указателя.

Так это в вашем примере кода именно так. У вас в функцию передаётся указатель, значение которого (не адрес самого указателя, а значение, хранящееся в указателя) не обязано быть выровнено по границе 32 бита, а обязано быть выровнено по границе 8 бит. Но почему-то вы говорите, что компилятор неадекватен, когда он соблюдает заданные ему ограничения. Притом, эти ограничения заданы в явном виде, а дальше приводится каст к типу, который должен быть выровнен по границе 32 бита. И этот каст, вашими словами выражаясь, сделал программист-идиот.

Изменено 7 июня, 2020 пользователем one_eight_seven

[aaarrr 69]

14 minutes ago, VladislavS said:

А носом в доку ткнуть, нет?

Хорошо, поиграем в Шерлоков:

Quote

компилятор от разработчиков ядра

как бы намекает, что речь идет о armcc из тех времен, пока они не метнулись на clang. А там, внезапно, тоже __packed.

[VladislavS 39]

1 минуту назад, aaarrr сказал:

Хорошо, поиграем в Шерлоков

ARMCC v6 (он же clang). Ну и GCC c IAR заодно. Код должен всем собираться.

[aaarrr 69]

1 minute ago, VladislavS said:

ARMCC v6 (он же clang). Ну и GCC c IAR заодно. Код должен всем собираться.

Я только играю бесплатно.

[repstosw 18]

15 minutes ago, one_eight_seven said:

Так это в вашем примере кода именно так

 

Я не приводил от себя лично никакого кода. Не надо шить мне то, чего я не делал.  

[VladislavS 39]

5 минут назад, aaarrr сказал:

Я только играю бесплатно.

Ну, то есть, бла-бла? Конечно, проще обвинить человека в нежелании читать доки. Спасибо.

[jcxz 245]

43 минуты назад, __inline__ сказал:

Здесь  uint8_t *src - указатель, адрес которого должен быть выровнен как минимум на 4 байта.

Из чего Вы заключили, что он "должен быть выровнен как минимум на 4 байта"? 

Как это следует из void WriteFIFO(uint8_t *src)?

25 минут назад, __inline__ сказал:

Ну так здесь программист - идиот.   Мы говорили про компилятор вообще-то.  А вы с jcxz упорно   продолжаете фабриковать  примеры, где  программист намеряно допустил передачу невыровненного указателя.

В исходном примере у VladislavS так и есть - программист намеренно допустил передачу невыровненного указателя. Только почему он вдруг "идиот"? Он ведь этого и хотел.

Просто при приведении типа к указателю на 32-битное значение, он забыл сказать компилятору, что указатель может быть невыровненным (указать модификатор __packed или его аналог).

[repstosw 18]

7 minutes ago, jcxz said:

Из чего Вы заключили, что он "должен быть выровнен как минимум на 4 байта"? 

Как это следует из void WriteFIFO(uint8_t *src)?

 

Это следует исходя из анализа тела этой функции.  Если коллега VladislavS читает или пишет  32-битными словами, то КО что указатель в параметре функции должен быть выравнен и это - забота программиста. А вот внутренний указатель что fifo должен быть выровнен компилятором, и если это не так, то компилятор неадекватен.

 

 

 Но VladislavS нигде не упоминал, что в качестве параметра функции он использовал невыровненный указатель. Поэтому я заключил следующее, раз VladislavS передаёт выровненный указатель, а получает эксепшн, значит проблема во втором указателе - который внутри функции и обязан быть выровнен

Изменено 7 июня, 2020 пользователем repstosw

[aaarrr 69]

3 minutes ago, VladislavS said:

Ну, то есть, бла-бла? Конечно, проще обвинить человека в нежелании читать доки. Спасибо.

Нет, всё же правду говорят, что наглость - второе счастье

 

Но, так и быть, намекну: сдается мне, все перечисленные тулчейны удовлетворятся gcc'шным синтаксисом.

[jcxz 245]

3 минуты назад, __inline__ сказал:

Это следует исходя из анализа тела этой функции.  Если коллега VladislavS читает или пишет  32-битными словами, то КО что указатель в параметре функции должен быть выравнен и это - забота программиста. А вот внутренний указатель что fifo должен быть выровнен компилятором, и если это не так, то компилятор неадекватен.

Так у VladislavS у исключение происходит не на записи *fifo, а на чтении *(uint32_t *)src !

3 минуты назад, __inline__ сказал:

Но VladislavS нигде не упоминал, что в качестве параметра функции он использовал невыровненный указатель. Поэтому я заключил следующее, раз VladislavS передаёт выровненный указатель, а получает эксепшн, значит проблема во втором указателе - который внутри функции и обязан быть выровнен

Нет, он именно передаёт невыровненный. А компилятор думает, что выровненный.

 

Кста: хоть IAR и не использует LDM/STM для оптимизации множества чтений/записей, но я как-то налетал на что-то похожее только на 64-битном доступе. Написал:

*(u64 *)ptr и получил закономерный HF, так как LDRD.

Когда исправил на *(__packed u64 *)ptr - всё стало ок, так как IAR разложил это на две LDR.

[VladislavS 39]

3 минуты назад, aaarrr сказал:

Нет, всё же правду говорят, что наглость - второе счастье

Ну же, сделайте последний шаг. Напишите что вот в это выражение добавить, чтобы компилятор использовал только LDR и никак не LDM?

*fifo = *(uint32_t *)src;

 

14 минут назад, jcxz сказал:

Просто он забыл указать __packed.

Думаете это так просто сделать? Ну вот, пробую в дурку с компилятором сыграть

using packed_uint32_t = uint32_t __attribute__((packed));
*fifo = *(packed_uint32_t *)src;

Компилируется, но покрутив у виска опять LDM влепил.

[jcxz 245]

4 минуты назад, VladislavS сказал:

Думаете это так просто сделать? Ну вот, пробую в дурку с компилятором сыграть

Я не знаком с вашим компилятором, но может так?:

typedef u32 __attribute__((packed)) u32p8;

или 

typedef __attribute__((packed)) u32 u32p8;

 

Другой вариант: Объявить тип структуры (пакованной) с единственным членом. И приводить к указателю на неё. Пакованную структуру то объявить ведь можно у вас?

[repstosw 18]

9 minutes ago, VladislavS said:

Думаете это так просто сделать? Ну вот, пробую в дурку с компилятором сыграть

 

9 minutes ago, VladislavS said:

Компилируется, но покрутив у виска опять LDM влепил.

 

GCC ?

 

https://stackoverflow.com/questions/34951458/why-does-gcc-produce-illegal-unalign-accesses-for-arm-cortex-a9

 

-mno-unaligned-access
  

 

Изменено 7 июня, 2020 пользователем repstosw

[VladislavS 39]

1 минуту назад, __inline__ сказал:

GCC ?

Да чтож у вас со зрением то? ARMCC v6.

2 минуты назад, __inline__ сказал:

-mno-unaligned-access

Мне НУЖЕН невыровненный доступ. Я за него борюсь :)

 

Ещё раз для понимания. У меня нет проблем с этим кодом! Я знаю как его компилируют ARMCC v6, GCC и IAR на всех возможных ключах оптимизации. Давно сделано всё что надо, чтобы проблема не вылезла больше. А вот как сказать на С/C++ компилятору, что я хочу невыровненный 32-битный доступ...

 

12 минут назад, jcxz сказал:

typedef u32 __attribute__((packed)) u32p8;

Ну это то же самое что и выше с using.