KostyantynT
Dec 19 2011, 08:56
Есть работающее устройство на базе omapl-137. ARM9 и DSP разогнаны до 400 мГц. На DSP крутится серьезный алгоритм обработки данных. На арме тоже приходится помимо фронтэнда на базе Qt, считать достаточно сложные алгоритмы с float арифметикой. Поэтому у арма серьезная загрузка. Работает это хозяйство под Linux.
Возникла идея использовать DSP как FP сопроцессор для арма. Например, по определенным адресам в Shared memory кладем два float аргумента и команду для вычисления. Вызываем прерывание DSP, он обрабатывает данные и кладет результат обратно. Все это время арм опрашивает флаг готовности данных, по получению флага - забирает результат. Что имеем:
1. DSP занят своим основным алгоритмом, периодически отвлекаясь на запросы арма, "посчитай мол".
2. Ускорение float в десятки раз для арма.
3. Не требуется переписывание всего отлаженного алгоритма или его частей под DSP.
4. Простой алгоритм обмена, требуется только сделать ремапинг shared memory/
5. В библиотеку можно включить код проверки загрузки DSP приложеним, если оно не загружено, то использовать стандартные float вычисления.
От техасовских монструозных библиотек обмена между DSP и ARM отказался и использую свой самописный UIO драйвер, чему несказанно рад.
Сразу возникает вопрос.
1. Как указать компилятору GCC, что мы используем свой FP сопроцессор.
2. Какие операции помимо умножения деления выполняет стандартный FP сопроцессор ARM?
Просьба покрититиковать или посоветовать по данному подходу.
Есть сомнения по поводу ускорения на одиночных операциях с плавающей точкой описанным Вами методом...
1. Издержки на обработчик исключения ARM
2. Издержки на вход в прерывание DSP
3. Издержки на чтение флага готовности.
Но раз хотите...
ARM компилятору указываете использовать VFP (сопроцессор арифметики с плавающей запятой).
Теперь у Вас при выполнении инструкции по работе с плавающей точкой возникнет исключение и процессор перейдёт в режим "Undefined mode" (неизвестная инструкция) - конечно неизвестная! аппаратного-то VFP нет!!
Тут-то Ваш обработчик может определить, что за инструкция вызвала исключение, декодировать её, отправить на выполнение DSP, дождаться результата, записать его в нужные регистры и вернуться в исходный код.
aaarrr
Dec 19 2011, 19:33
Боюсь, это будет в конечном счете медленнее эмуляции float'а непосредственно arm'ом.
sasamy
Dec 19 2011, 23:20
Цитата(sysel @ Dec 19 2011, 23:22)

Теперь у Вас при выполнении инструкции по работе с плавающей точкой возникнет исключение и процессор перейдёт в режим "Undefined mode" (неизвестная инструкция) - конечно неизвестная! аппаратного-то VFP нет!!
Тут-то Ваш обработчик может определить, что за инструкция вызвала исключение, декодировать её, отправить на выполнение DSP, дождаться результата, записать его в нужные регистры и вернуться в исходный код.
Зачем такие извраты ? Это на порядок медленней програмной эмуляции в юзерспейс:
http://gcc.gnu.org/wiki/Software_floating_pointhttp://gcc.gnu.org/onlinedocs/gccint/Soft-...y-routines.htmlтем более для этого уже все есть
Цитата
От техасовских монструозных библиотек обмена между DSP и ARM отказался и использую свой самописный UIO драйвер,
KostyantynT
Dec 20 2011, 09:58
Цитата(sasamy @ Dec 20 2011, 03:20)

Зачем такие извраты ? Это на порядок медленней програмной эмуляции в юзерспейс:
http://gcc.gnu.org/wiki/Software_floating_pointhttp://gcc.gnu.org/onlinedocs/gccint/Soft-...y-routines.htmlтем более для этого уже все есть
Ок, спасибо за наводку, те я должен реализовать вышеуказанные функции и подсунуть компилятору свою библиотеку. Как указать GCC компилятору чтобы он использовал мою библиотеку вместо вызова функций из libgcc? Для начала можно попробовать реализовать несколько функций и прогнать тесты Whetstone.