TNKernel будет ли порт для cortex m4 ? Опции

[dimanisu]

Здравствуйте!

У меня вопрос к разработчику ОС Юрию и всем, кто допиливал ось под себя(VslavX и т.д.), озвученный в названии темы. Будет ли такой порт? Планирую работать с STM32f4.
Планируется ли дальнейшее развитие TNKernel?

Заранее благодарен за ответы.

[VslavX]

По теме переключения контекста FPU по требованию (по исключению) тоже хотелось бы услышать мнение All. После обдумывания мне кажется что хранить контекст FPU в стеке уже нельзя - иначе его будет невозможно восстановить по требованию (задача выполняется уже при произвольном стеке, и тут ей понадобился FPU - а стек-то уже тю-тю). Поэтому предлагается хранить контекст в блоке задчаи - TN_TCB. Но тут минус что контекст FPU большой - от 128 байт, и не каждая задача использует FPU - не всем оно надо. Поэтому предлагается завести пул блоков, для сохранения контекста. Когда задача начинает юзать FPU ей оттуда выделяется блок (ссылка храниться в TCB) и далее она пользуется блоком. При завершении задачи - блок возвращается. Таким образом пользователь может определить пул нужного размера - по числу задач работающих с FPU. Поддержку FPU в обработчиках прерываний/исключений думаю не реализовывать - код усложняется, скорость падает.

P.S. А чем бы float/double на консоль выводить, а то мой самописный printf не поддерживает %f, %e, %a - наверное, пришло время добавить эту поддержку. Посмотрел реализации glibc - так там еще длинную арифметику надо. uglibc тоже не радужно. Может кто-то присоветует относительно более простое решение?

Update: разобрался я с FPSCR, он автоматически в стеке сохраняется. При моем методе надо будет делать руками, главное - не забыть

[AHTOXA]

Я бы для начала попытался проанализировать плюсы и минусы вашего метода при различных сценариях использования.
Сценарий первый: в данный момент времени две задачи (или более) работают с плавучкой. При таком сценарии, насколько я понял, после каждого переключения контекста на "плавучую" задачу будет происходить много чего: исключение, выяснение причины, сохранение контекста предыдущей задачи, поиск свободного пула для сохранения контекста новой задачи... То есть, это всё будет работать сильно медленнее, чем простой вариант а-ля FreeRtos.
Сценарий второй (выигрышный для вашего варианта): Все задачи (или все кроме одной) перестали работать с плавучкой. В этом случае ничего не происходит, всё работает как M3.
Мне кажется, что второй вариант будет встречаться значительно реже. К тому же, к FreeRtos-ному варианту можно просто добавить функцию окончания работы с плавучкой, типа tn_end_fpu(), в которой будет сбрасываться бит CONTROL.FPCA. В этом случае он не уступит вашему варианту и при втором сценарии (если конечно все задачи вызовут tn_end_fpu()).

[VslavX]

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

Основной анализ проделан в статье ARM на которую Вы уже давали ссылку. Там же оба подхода довольно подробно рассмотрены. Из дополнительных минусов второго ("переключение по требованию") я вижу невозможность (хотя, скорее громоздкость и неудобство) использования FPU в обработчиках прерываний/исключений. Зато снижается оверхед при переключении контекста и interrupt latency.

Сценарий первый: ...
...
Сценарий второй ...

С анализом сценариев у меня туго . На данный момент у меня такого рода задачи, что я вообще не понимаю зачем нужен FPU. Будучи студентом в университете приходилось заниматься численным моделированием плазмы. На Фортране-IV. На СМ-4. Предметом гордости было наличие блока FIS. Потом кафедра купила СМ-1420 с полноценным FPP - радости было. Но сейчас таких задач у меня нет - скрипач FPU не нужен. Поэтому мне сложно сказать какой сценарий более частый и предпочтительный, и планирую реализовать оба подхода, с выбором по флагу компиляции. Второй сценарий сделаю несколько упрощенным - для начала не буду заморачиваться с пулом, просто буду хранить контекст в TCB.

Если кто-то реально использует (или только планирует использовать) FPU в своих приложениях - то было бы интересно узнать какой типовой способ использования в разрезе RTOS - сколько задач используют FPU, есть ли использование FPU в обработчиках прерываний и прочее.

(если конечно все задачи вызовут tn_end_fpu()).

ИМХО такая функция полезна при обоих подходах. Если пользователя заботит быстродействие то ему надо предоставить возможность такой настройки.

Update:
Вот такое "понравилось":

"GNUC C compiler (gcc)
If a program is compiled with the FPU option, gcc might make use of the floating-point registers
if register pressure is high, and running low on available registers for data processing. In some
cases, the memory copy might also utilize floating-point registers to hold data"

Соглашение ABI при наличии FPU разрешает его почти произвольное использование - даже если нет работы с данными типа float/double, регистры FPU все равно могут использоваться компилятором, хотя бы в качестве быстрого хранилища переменных. Поэтому весь код обработчиков прерываний (включая системные функции типа tn_sem_isignal()) нужно компилировать с -mfloat-abi=soft. И библиотеки тоже с такой опцией. И, соответственно, приложение - иначе несовместимость линковки (хотя, проверю линковку "soft" и "softfp", есть шанс). И кому такое надо - вообще не моги пользовать FPU? Получается что второй подход для систем с отдельной линковкой приложения. Разрешить использование FPU в обработчиках можно, но для этого надо для каждого сделать отдельную функцию-переходник в котором явно запрещается FPU - чтобы FPU-код в обработчике вызвал исключение. И такой переходник скушает почти весь выигрыш в быстродействии

Из компиляторов пока только Keil можно заставить не использовать FPU для "неплавучих" целей. GCC и IAR таких флажков не имеют.