[jcxz 182]

Столкнулся с очень неприятным моментом в работе IAR:

В какой-то момент заглянул в листинг и увидел, что копируя структуру, IAR использует регистры FPU!

Хотя и рядом нет никаких операций с плавучкой. Просто есть структура, есть две переменных типа этой структуры и есть операция копирования одной переменной в другую (присваиванием, без memcpy()). И я вижу что IAR 7.80.4 лепит такой код (с оптимизацией и без):

ADD      R2,SP,#+8
VLDM     R2,{D0-D3}
VSTM     R1,{D0-D3}

Что очень неприятно, ведь работа идёт под РТОС, в одной из задач ОС. В этой задаче нет никаких операций с плавучкой. Соответственно данная задача создаётся с указанием ОС что она не использует FPU. Соответственно ОС при переключении контекста с/в данную задачу не сохраняет/восстанавливает регистры FPU. Соответственно - будут разрушены регистры FPU в тех задачах, которые используют FPU (а также в тех, в коих IAR так же впихнул такое копирование через FPU).

Некоторые задачи в программе используют плавучку, значит полностью запретить FPU нельзя. Можно конечно сделать сохранение контекста FPU для всех задач вне зависимости от использования ими FPU, но не хотелось бы, так как все стеки задач придётся увеличить, увеличится время переключений контекста задач. Да и вообще - зачем? ОЗУ ведь не резиновая?

 

Как запретить IAR-у использовать регистры FPU для всего, кроме операций с плавучкой? Что-то в мануале не найду ничего про такое.... :((((((

[Arlleex 131]

Столкнулся с очень неприятным моментом в работе IAR...

Дык известное ж дело (вроде), что не только в IAR, оно везде так, думается мне. Keil также поступает в некоторых случаях, под Eclipse для Cortex-A тоже самое. Я не стал разбираться пока что досконально, почему код с применением регистров FPU будет работать быстрее. Но чую, что оно действительно так.

 

Что очень неприятно, ведь работа идёт под РТОС, в одной из задач ОС. В этой задаче нет никаких операций с плавучкой. Соответственно данная задача создаётся с указанием ОС что она не использует FPU.

Ух ты! А что у Вас за ОС? Почему во FreeRTOS такой возможности нет :crying:

 

Как запретить IAR-у использовать регистры FPU для всего, кроме операций с плавучкой? Что-то в мануале не найду ничего про такое.... :((((((

Ну не знаю насчет IAR, просто с сайта ARM Вам пищу для размышлений хочу указать. Оно как раз Вам подходит. Запрещает использовать FPU везде, где не пахнет операциями плавучки.

--no_allow_fpreg_for_nonfpdata

[AlexandrY 2]

Как запретить IAR-у использовать регистры FPU для всего, кроме операций с плавучкой? Что-то в мануале не найду ничего про такое.... :((((((

Вот это поворот!

Действительно при копировании 32-х и 64-х байтных структур IAR использует регистры FP сопроцессора.

И не лечится ничем.

Отключение оптимизации не помогает.

Просто запретить --fpu=none для отдельного файла компилятор не дает. Других опций и прагм нет.

Между тем в uCOS для портов на ARM под IAR повсеместно используется запрет на сохранение контекста FP.

В других осях тоже.

[jcxz 182]

почему код с применением регистров FPU будет работать быстрее. Но чую, что оно действительно так.

Скорость копирования в данном случае меня не интересует.

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

 

Ух ты! А что у Вас за ОС? Почему во FreeRTOS такой возможности нет :crying:

Дык - поэтому и не использую FreeRTOS, потому что там многого полезного нет :laughing:

У меня uCOS-II.

 

Ну не знаю насчет IAR, просто с сайта ARM Вам пищу для размышлений хочу указать. Оно как раз Вам подходит. Запрещает использовать FPU везде, где не пахнет операциями плавучки.

--no_allow_fpreg_for_nonfpdata

К сожалению IAR не понимает эту опцию. :( :( :(

 

Между тем в uCOS для портов на ARM под IAR повсеместно используется запрет на сохранение контекста FP.

В других осях тоже.

Вот именно!

Заметил только вчера эту пакость со стороны IAR-а. Сейчас думаю, что возможно какие-то случайные, редко-проявляющиеся баги, которые иногда возникают, могли быть вызваны этим.

Пока перевёл копирование структур на memcpy(). Но нет уверенности что IAR, при включённой оптимизации не станет шалить с регистрами FPU и в других местах, а не только при копировании структур. :(

[ih_ 0]

Столкнулся с очень неприятным моментом в работе IAR:

...

Какой МК?

 

[DASM 0]

Гм.. перекатил проект на юкосе на Гцц компилер - проблем не получил. Ну кроме выравнивания стека на 8, но там и для ИАР стояли директивы, сам виноват, не поставил аналогичные. Но чтобы с фпу засады.. гцц вроде не пакостил пока

 

Какой МК?

Неужели много вариантов с фпу стало , кроме кортексов 4ф и выше (ну и А серия)?

[jcxz 182]

Какой МК?

Cortex-M4F

 

Гм.. перекатил проект на юкосе на Гцц компилер - проблем не получил. Ну кроме выравнивания стека на 8, но там и для ИАР стояли директивы, сам виноват, не поставил аналогичные. Но чтобы с фпу засады.. гцц вроде не пакостил пока

Да, как-то печально. До сих пор уважал IAR..... :05:

[ViKo 1]

В тех задачах, где используется FPU, регистры сохранятся и восстановятся при входе и выходе. А в других... а сколько тех других? Одна?

[Сергей Борщ 119]

В тех задачах, где используется FPU, регистры сохранятся и восстановятся при входе и выходе.

Если такие задачи имеют наивысший приоритет и не могут быть вытеснены задачами, которые не сохраняют, но иногда портят регистры сопроцессора - будет работать.

[jcxz 182]

В тех задачах, где используется FPU, регистры сохранятся и восстановятся при входе и выходе. А в других... а сколько тех других? Одна?

Не одна, а большинство. У меня FPU используется не где попало, а только там где нужно.

 

Если такие задачи имеют наивысший приоритет и не могут быть вытеснены задачами, которые не сохраняют, но иногда портят регистры сопроцессора - будет работать.

Любая задача может быть вытеснена, вне зависимости от её приоритета, так как любая использует хотя-бы один объект синхронизации ядра (семафоры, мьютексы и т.п.).

К тому же назначение приоритетов должно делаться не по багам компилятора, а по требованиям прикладной задачи. Как можно назначить наивысший приоритет задаче, которая массивно выполняет операции с плавучкой (обработка данных) и убить этим работу всех реалтаймовых задач, например: драйверов устройств, которые не требуют большого времени выполнения, но требуют быстрой реакции на события в периферии?

Мои проекты насыщены разнообразной периферией и, соответственно, много драйверов устройств. Но при этом в паре-тройке мест нужно периодически обработать плотно данные на FPU (фильтрация).

[ViKo 1]

Не одна, а большинство. У меня FPU используется не где попало, а только там где нужно.

Нет, сколько задач с присвоением одной структуры другой? Может, компилятор неким образом держит под контролем такую ситуацию?

[scifi 1]

Раскидать задачи по разным файлам и компилировать с разными ключиками: одни для CM3, другие - CM4F. Вероятно, линкер будет отказываться их скрестить, надо как-то побороть.

[jcxz 182]

Нет, сколько задач с присвоением одной структуры другой? Может, компилятор неким образом держит под контролем такую ситуацию?

Теперь уже ни одной. Прошерстил исходники и все такие места заменил на memcpy().

 

Раскидать задачи по разным файлам и компилировать с разными ключиками: одни для CM3, другие - CM4F. Вероятно, линкер будет отказываться их скрестить, надо как-то побороть.

Да, вариант. В крайнем случае видимо можно так и поступить.

Пока обошёлся memcpy() как менее травмирующим решением. И надеюсь что IAR-овцы не додумаются и внутренности memcpy() оптимизировать с помощью FPU... :05:

А то придётся библиотечный memcpy() заменять на свою ассемблерную реализацию.

[Сергей Борщ 119]

Любая задача может быть вытеснена, вне зависимости от её приоритета, так как любая использует хотя-бы один объект синхронизации ядра (семафоры, мьютексы и т.п.).

При работе с объектом синхронизации задача не вытесняется в произвольном месте, а отдает управление с сохранением своего контекста (включая регистры сопроцессора).

 

К тому же назначение приоритетов должно делаться не по багам компилятора, а по требованиям прикладной задачи.

Естественно. Я отвечал на сообщение ViKo, где он утверждал, что достаточно сохранять регистры сопроцессора в "нужных" задачах, а остальные могут их портить.

[jcxz 182]

При работе с объектом синхронизации задача не вытесняется в произвольном месте, а отдает управление с сохранением своего контекста (включая регистры сопроцессора).

А какая разница? Контекст то ведь будет сохранять та же функция ОС, которая сохраняет и при вытеснении в тот же формат.

Или задача сама отдаёт управление, передавая свои регистры переключателю контекста, или она вытесняется ISR-ом, который кладёт часть её регистров в стек и потом если нужно передаёт переключателю контекста - разницы нет.