Операции с плавающей точкой в ​​обработчике прерываний (PowerPC, VxWorks)

Question

Я не нашел никаких ресурсов, которые бы точно отвечали тому, что я пытаюсь понять, с проблемой, которую я видел в программном обеспечении, над которым я работаю, поэтому я спрошу здесь гениев!

Для начала я использую VxWorks на процессоре PowerPC.

Пытаясь отладить отдельную проблему, я попытался добавить несколько быстрых и грязных отладочных кодов в процедуру обработки прерываний. В нем использовалась операция с плавающей запятой двойной точности для хранения значения, представляющего интерес (а именно, сколько времени прошло с тех пор, как я увидел, как появилось последнее прерывание), которое я использовал позже вне обработчика в моем рабочем потоке. Я не видел проблемы в этом (конечно, это занимает больше времени, но со временем у меня было достаточно времени; прерывания не приходят слишком быстро), но VxWorks наверняка это не понравилось. Он последовательно вылетает, когда достигает этого кода, один из плохих сбоев, который перезагружает систему. Мне потребовалось немного времени, чтобы отследить двойную операцию как источник проблемы, и я понял, что это даже не двойные «операции», даже возвращение постоянного двойного значения из подпрограммы, вызываемой в прерывании, с треском провалилось.

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

(Обходным решением было задержать преобразование «тиков» с момента последнего прерывания во «время», начиная с последнего прерывания до тех пор, пока код не выйдет из обработчика, поскольку кажется, что он отлично обрабатывает длинные целочисленные операции.)

Answer 1

В VxWorks каждая задача, которая использует плавающую точку, должна быть указана как таковая при создании задачи, чтобы регистры FP сохранялись во время переключения контекста, но только при переключении из задач, которые используют плавающую точку.Это позволяет задачам без плавающей запятой иметь более быстрое время переключения контекста.

Однако, когда прерывание опережает задачу с плавающей запятой, наиболее вероятно, что регистры FP не сохранены.Для этого обработчик прерываний должен будет определить, какая задача была прервана и была ли она задана как задача с плавающей запятой;это сделало бы задержку прерывания как высокой, так и переменной, что, как правило, нежелательно в системе реального времени.

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

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

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

Answer 2

Ваш ISR вызывает функции fppSave () / fppRestore ()?

Если это не так, то ISR топает регистры FP, которые могут использоваться существующими задачами.

В частности, регистры FP используются компилятором C ++ в архитектуре PPC (я думаю, что имеет дело с throw / catch).

Answer 3

Общее предположение в VxWorks состоит в том, что регистры с плавающей запятой не должны быть сохранены и восстановлены ISR.Прежде всего потому, что ISR обычно не связываются с ними.Исторически сложилось так, что большинство задач в реальном времени не выполняли FP, но это явно изменилось.Что не очевидно, так это то, что многие задачи, которые явно не используют числа с плавающей запятой, тем не менее, используют регистры с плавающей запятой.Я считаю, что любая задача с кодом, написанным на C ++, использует регистры с плавающей запятой (по крайней мере, на некоторых процессорах / компиляторах), хотя никакие операции с плавающей запятой не очевидны.Такие задачи должны быть даны FP_?(Я забыл точное написание) атрибут задачи, в результате чего их регистры FP сохраняются во время переключения контекста.

Answer 4

Я работал с ядром e300 при разработке приложений на «голое железо» и могу сказать, что при возникновении прерывания ядро ​​закрывает FPU, что можно наблюдать, проверяя бит FP MSR.Прежде чем что-либо делать с регистрами с плавающей запятой, вы должны снова включить FPU, записав 1 в FP бит MSR.Затем вы выполняете операции с регистрами FPU, как хотите в ISR.

Answer 5

В VxWorks, по крайней мере для архитектур PPC, операция с плавающей точкой вызовет исключение Unavilable FP. Это связано с тем, что при возникновении прерывания бит FP в MSR очищается, поскольку VxWorks предполагает, что операций FP не будет. Это ускоряет переключение контекста ISR / Task, поскольку регистры FP не нужно сохранять / восстанавливать.

При этом было время, когда у нас был некоторый отладочный код, для которого нам требовались операции FP в контексте прерывания. Мы изменили код VxWorks, который вызывает конкретный ISR, на 1) установите MSR [FP], выполните вызов fpsave, вызовите ISR, выполните вызов fprestore, затем очистите MSR [FP]. Это помогло нам решить проблему.

При этом я согласен с остальными здесь, что операции FP не должны использоваться в контексте ISR, потому что ISR должны быть быстрыми, а операции FP обычно - нет.

Answer 6

Я думаю, вы найдете эту статью интересной.Возможно, вы попадаете в исключение с плавающей запятой.

Я никогда не использовал PowerPC, но у меня все хорошо с Google: P