Как отучить IAR использовать регистры FPU где не нужно? Опции

[jcxz]

Столкнулся с очень неприятным моментом в работе 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 для всего, кроме операций с плавучкой? Что-то в мануале не найду ничего про такое.... (((((

[ViKo]

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

[jcxz]

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

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

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

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

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

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

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

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

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

[jcxz]

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

А какая разница? Контекст то ведь будет сохранять та же функция ОС, которая сохраняет и при вытеснении в тот же формат.
Или задача сама отдаёт управление, передавая свои регистры переключателю контекста, или она вытесняется ISR-ом, который кладёт часть её регистров в стек и потом если нужно передаёт переключателю контекста - разницы нет.

[ih_]

А какая разница?...

Есть разница. У некоторых МК РОНы отображаются на память. И если в Вашем случае это так, то я хотел предложить создать по этому адресу volatile переменную, тогда компилятор не посягнул бы на эту область памяти - регистр.

[jcxz]

Есть разница. У некоторых МК РОНы отображаются на память. И если в Вашем случае это так, то я хотел предложить создать по этому адресу volatile переменную, тогда компилятор не посягнул бы на эту область памяти - регистр.

Я писал выше - у меня Cortex-M4. У него регистры никуда не отображаются.

Т.е. если компилятор объявил макрос __ARMVFP__ , то все задачи без исключения сохраняют контекст fpu.
Другое дело, что в startup файлах из bsp может случайно не взводится флаг FPCA в регистре CONTROL, допустим проигнорен вызов __iar_program_start, и прерывания по умолчанию не сохраняют контекст fpu.

И FPCA и ASPEN и LSPEN (в FPCCR) у меня сброшены. И сброшены не случайно, поверьте про них я знаю. Сброшены потому что в ISR-ах в этом проекте плавучку не использую.
Я не знаю как там дела обстоят в uCOS-III, у меня uCOS-II. И читать и понимать исходники я думаю что умею. Эта функция в uCOS-II вызывается при переключении активной задачи:

CODE

#if (OS_CPU_HOOKS_EN > 0u) && (OS_TASK_SW_HOOK_EN > 0u)
void OSTaskSwHook (void)
{

#if (OS_CPU_ARM_FP_EN > 0u)
if ((OSTCBCur->OSTCBOpt & OS_TASK_OPT_SAVE_FP) != (INT16U)0) {
OS_CPU_FP_Reg_Push(OSTCBCur->OSTCBStkPtr);
}

if ((OSTCBHighRdy->OSTCBOpt & OS_TASK_OPT_SAVE_FP) != (INT16U)0) {
OS_CPU_FP_Reg_Pop(OSTCBHighRdy->OSTCBStkPtr);
}
#endif

#if OS_APP_HOOKS_EN > 0u
App_TaskSwHook();
#endif
}
#endif

OS_CPU_HOOKS_EN, OS_TASK_SW_HOOK_EN, OS_CPU_ARM_FP_EN - все равны 1.
OS_CPU_FP_Reg_Push и OS_CPU_FP_Reg_Pop - тоже не пустые и делают то, что и полагается.
Обратите внимание на OS_TASK_OPT_SAVE_FP - именно этот флаг передаётся в аргументе prio (6-й бит) и говорит ОСи что задача юзает FPU и что нужно в сохраняемый/восстанавливаемый контекст для данной задачи включить регистры FPU.
Более того - одна из задач (Idle-задача) у меня имеет размер стека == 64 байта, т.е. - только-только чтобы сохранить регистры CPU, и если-бы туда сохранялись ещё и регистры FPU, то данные выше этого стека были бы снесены, а там весьма важные данные и они не портятся.
Да и отладчиком я пользоваться умею всё-таки...

А что, флажок который говорит что FPU поюзали и его надо сохранить - отменили?

Когда FPU поюзала процедура копирования, то сохранять уже поздно.

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

Да, Вы правы, именно в таком случае. Когда задача копирует через FPU, то значит она в этот момент активная, а все остальные задачи выгружены в память (все их копии регистров FPU все находятся в памяти). И естественно в этом случае она не может эти данные попортить. Но вот её данные - попортить могут.

PS: Кстати - Ваше замечание навело меня на мысль, что в качестве костыля можно на время копирования структур запрещать прерывания (критическая секция).
Правда нет гарантии, что при копировании просто нескольких переменных, расположенных рядом, оптимизатор не захочет также прибегнуть к FPU. Или не копировании, а заполнении их константой.

[AlexandrY]

Я не знаю как там дела обстоят в uCOS-III, у меня uCOS-II. И читать и понимать исходники я думаю что умею.

За uCOS-II я не писал, как раз чтобы вам предоставить возможность высказаться.

Все идет к тому что надо переходить на mbed. Самая нативная RTOS.

[jcxz]

Все идет к тому что надо переходить на mbed. Самая нативная RTOS.

А толку? как это поможет? IAR, узрев её исходники, сразу поостерегётся своевольничать?

[AlexandrY]

А толку? как это поможет? IAR, узрев её исходники, сразу поостерегётся своевольничать?

Да нет, просто в IAR 8.30 появился неплохой плагин под mbed. Можно уже нормально юзать. А там самый короткий переключатель контекста.

Кстати, в версии 8.30 у меня не получилось заставить использовать fpu при копировании структур.
Так что тревога отменяется.

А я сразу подумал о таком решении, но постеснялся предлагать очевидное.

Если речь идет об ISR уровня ядра длительностью в 0.5 мкс и джитером 0.1 мкс , то такой путь неприемлем.
Хотя кому в голову придет в таких ISR копировать структуры!?