Выполнил черновой перенос существующего кода порта для Cortex-M3 (в который буду добавлять код для M4F) под GCC.Погонял тестовый код на Discovery STM32F4xx под IAR 5.41, IAR 6.40, GCC CodeSourcery (4.7.2 менторовский релиз 63) и упомянутый в этой ветке GNU Tools for ARM Embedded Processors.

По компактности сгенерированного кода (в порядке от меньшего к боьшему размеру)
- IAR 5.x - 11632
- IAR 6.x - 13344
- GCC CS - 13344
- Toolchain - 14816

По быстродействию (переключение контекста / Dhrystone, не особо показательно, разница маленькая):
- IAR 6.x (0.920 мкс) - 246502 DS
- IAR 5.x (1.080 мкс) - 246850 DS
- GCC CS (1.040 мкс) - 250490 DS
- Toolchain (1.080 мкс) - 250936 DS

Тест Dhrystone гонял, но он тоже не показателен - примерно 250000 у всех, +/- пару процентов. При модификации кода показатели меняются (видимо смещается как-то оно во флешке и начинает играть акселератор).

Исходники компилируются обоими компиляторами GCC - CS/Toolchain, никаких уcловных веток между ними нет. Но мне пока CodeSourcery нравится больше - документация получше, код покомпактнее. И вроде бы поддерживает LTO, но ключики -flto компилятору и линкеру на результирующий файл влияния не оказали. Toolchain на -flto варнингует.

В-общем, следующий шаг - уже буду собственно плавучку прикручивать, тут CodeSourcery в бесплатной редакции Lite может подбросить фокусов - вроде там были искусственные ограничения на hard-FPU. Буду разбираться дальше.

А вот с этим: arm-none-eabi кто нибудь, работал?

Именно про него парой постов выше упоминали аж несколько авторов.

Именно Линуксовая версия интересует? Я тестировал в этом топике версию с того же launchpad.net, но под Cygwin. Вроде же разницы на генерируемом выходном файле быть не должно?

Да, именно линуховый вариант интересует, и в самом линухе.
Извиняюсь з аоффтопик, но может кто-то подскажет?
С помощью этого тулчейна можно компильнуьб рабочий бинарник для:


Сообщение отредактировал Volldemar - Feb 20 2013, 12:32

Разницы нет.


Насколько мне известно, этот тулчейн заточен под Cortex-M/R семейства.

По теме переключения контекста 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, он автоматически в стеке сохраняется. При моем методе надо будет делать руками, главное - не забыть

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

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


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

Если кто-то реально использует (или только планирует использовать) FPU в своих приложениях - то было бы интересно узнать какой типовой способ использования в разрезе RTOS - сколько задач используют FPU, есть ли использование 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 таких флажков не имеют.

Реализовал оба метода переключения контекста.
Метод 1: использование автоматического "ленивого" сохранения контекста FPU в стеке, полностью аналогичен коду порта scmRTOS
Метод 2: метод переключения контекста по требованию. Имеется системная переменная - указатель на TCB задачи, контекст которой загружен в данный момент в регистры FPU. При переключении задачи эта переменная сравнивается с TCB загружаемой задачи. При совпадении доступ к FPU разрешается через биты регистра CPACR, иначе доступ запрещен. Когда текущая задача, не владеющая контекстом FPU пытается выполнить плавучую операцию - происходит исключение, сохраняющее регистры FPU в TCB задачи-владельца, и загружающее нужный контекст текущей задачи.
Предварительно потестировал оба метода.
Для начала картинка GCC<->IAR без поддержки FPU

Мой взгляд, разницы принципиальной нет.

Теперь картинка сравнения разных методов, для компилятора GCC.

FPU1 - метод 1
FPU2 - метод 2
none - ни одна из двух тестовых задач не обращается к FPU
Task1 - только первая тестовая задач обращается к FPU
Task2 - только вторая тестовая задач обращается к FPU
Task12 - первая и вторая тестовая задачи обращаются к FPU

Для метода 1 следует помнить, что FPCA бит в регистре CONTROL является sticky - то есть если задача хотя бы раз (возможно в далеком прошлом) обратилась к FPU и теперь про него вообще забыла - крайняя левая картинка уже использоваться не будет - работает одна из правых. С явным сбросом FPCA могут быть проблемы, так как компилятор может неявно использовать FPU даже в отсутствие операций с float/double.

Для метода 2 есть недостаток - не поддерживается FPU в прерываниях/исключениях. В связи с этим для гарантии код операционной системы следует компилировать с оцпией -mfloat-abi=soft. А приложение и математические библиотеки с опцией softfp. Иначе оно не будет линковаться. На ассемблер разумеется никаких ограничений.

Еще немного потестирую и буду прикручивать к официальной версии 2.6. Кстати, там видно что пооптимизировать, предложу модификации.

Update: еще покрутил ассемблерный листинг - для метода 2 времянки еще улучшились немного. На крайней правой нижней картинке теперь общее время 3.73мкс. Можно еще уменьшить за счет удаления всяких проверок (типа не пришло ли исключение из режима обработчика), но это уже может сказаться на надежности.

Update 2: у меня тут префетч из флеша в тесте выключался оказывается, почему то заметно влияло только на самую нижнуюю правую картинку - итого полное время 3,30 мкс для метода 2.

Update 3: тестирование прошло удачно, обновил картинку с цифрами. Префетч включен

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

Сейчас я убегаю, поэтому - по быстрому - фрагмент тестового кода:



Вечером продолжу тестирование и буду уже смотреть официальную ветку, там тоже есть что обсудить.
P.S. А префетч я отключал чтобы по-честному соревноваться с Вашими тестами scmRTOS - у Вас там ревизия проца старая
P.P.S. Картинки уже устарели - есть круче

Не могли ли бы вы поделиться проектом? У меня, к сожалению сделать это не получилось.
Программа постоянно прыгает по "OS timer tick" в tn_timer_task_func с периодической обработкой SysTick_Handler, но никак не переходит в функцию моей единственной задачи.
Буду благодарен любой помощи, мое первое знакомство с tn_kernel. Работаю все на той же stm32f4discovery под mdk-arm.

Порт "официальной" ветки и пример под stm32f4xx готовы, к сожалению, под IAR/GCC. Также внесена часть моих оптимизаций - которые вносятся без глубокого хирургического вмешательства. Осталось написать "сопроводиловку" и еще немного потестировать (там аж 8 вариантов компиляции нарисовалось) - и будет открыто.

TNKernel порт для Cortex-M4, написанный VslavX, выложен на сайте www.tnkernel.com.

Просьба со всеми вопросами обращаться непосредственно к автору ( VslavX )