Операции с плавающей точкой без FPU, На сколько падает производительность? Опции

[sigmaN]

Интересно, а можно ли на целочисленном DSP с запасом производительности(скажем в 3-5 раз) зарулить вокодер на плавающей точке?

И вообще, каков overhead, так сказать, FP операций на проце без FPU?
Страдает ли точность вычисления?
Что нужно для подобных "извращений"?
Может быть есть какая-то библиотека виртуального FPU, так сказать?
DSP Техас 55 серии.

[fontp]

Можно, только не в 3-5, а скорее раз 8-10
Для этого обычно строят библиотеки "короткого" нестандартного FP
Чтобы удобно (т.е. быстро) было работать. Слово мантисы + слово экспоненты
И никаких проверок на потерю точности - с ними всё равно нечего делать в риал-тайме
Ещё они должны быть inline, иначе труба
Такие библиотеки есть. Можете и сами написать умножение деление сложение и вычитание.
Преобразование типа из/в int и float можно где-нибудь найти на С
Если Вы хотите приспособить к SPEEX без переписывания, то проблемы всё равно останутся.
Во-первых операторами можно оформить только в СPP, в С это функции/ SPEEX это С, а значит...
Во-вторых в чужих проектах используются стандартные математические библиотеки math.h,
а это уж точно прийдётся самому писать под новый тип новую реализацию - sin, sqr, и что там ещё есть в SPEEX

[sigmaN]

Можно, только не в 3-5, а скорее раз 8-10

Да уж... труба дело :-)
Неужели всё-таки придется окунуться в математику и переписывать некоторые алгоритмы на целочисленную модель.
А есть где-нибудь мануальчики как это обычно делается.
Ну там, начиная от анализа существующего FP алгоритма и так далее чтобы на выходе был ФТ алгоритм.

Видимо от этого никуда не деться....:-(

[fontp]

Да уж... труба дело :-)
Неужели всё-таки придется окунуться в математику и переписывать некоторые алгоритмы на целочисленную модель.
А есть где-нибудь мануальчики как это обычно делается.
Ну там, начиная от анализа существующего FP алгоритма и так далее чтобы на выходе был ФТ алгоритм.

Видимо от этого никуда не деться....:-(

Если никуда не деться... Могу посоветовать AN EE-185 для BF
Там хоть преобразование типов есть на С, операции на асемблере (делать самому, если не знать его ассемблера, чтобы использовать как прототип), ну и вообще по тексту описание
FastFloat16 или FastFloat32
Это на www.analog.com Application Note
Как у ti c такими библиотеками - не знаю, возможно, что и есть
Математику, в смысле, стандартные функции с нужной точностью - самому


Потом грамотно целый класс в С++ накропать
Типа c таким прототипом
http://www.koders.com/cpp/fid5E90955711BFB...C383C.aspx#L103

Потом все модули SPEEX переименовать в cpp, компилировать и править ошибки :-)

[DRUID3]

Если никуда не деться... Могу посоветовать AN EE-185 для BF
Там хоть преобразование типов есть на С, операции на асемблере (самому, если не знать его ассемблера, чтобы использовать как прототип), ну и вообще по тексту описание
FastFloat16 или FastFloat32
Это на www.analog.com Application Note
Как у ti c такими библиотеками - не знаю, возможно, что и есть
Математику, в смысле, стандартные функции с нужной точностью - самому
Потом грамотно целый класс в С++ накропать
Типа c таким прототипом
http://www.koders.com/cpp/fid5E90955711BFB...C383C.aspx#L103

Потом все модули SPEEX переименовать в cpp, компилировать и править ошибки :-)

Я еще speex не собирал, и вот заинтересовался темой. Но...

во-первых - помниЦЦо в VDSP++ есть float для целочисленных процессоров. В чем проблема? На Bf все будет летать и так. Что надо переписывать? Я кода-то с float алгоритмы переносил на fix так и то вспоминать не хочу больше... а если еще самому мутить матлибу (пусть и "быстрый float")- это ошибки человека + ошибки принципиальные - ну как в fix с масштабированием.

во-вторых - насколько я понимаю Linuxовый Speex для bf - целочисленный...и он вполне собираеЦЦо...??? Есть целочисленный вход/выход, в портах для TMS и BF используются типы данных на основе int. ... Что еще надо для души?

Ну и в-тетьих, если так хочеЦЦо float - то у AD есть серия дешевых SHARKов, они собственно для того и создавались что-бы не ломая голову применять акадэмические(книжные) алгоритмы. Тем более что их производительности хватит еще на корзинку таких speexов...

P.S.: собственно мне не понравился подход... не хочу чтобы медаппаратуру, например, даже для зубного кабинета, разрабатывали так...

[fontp]

Я еще speex не собирал, и вот заинтересовался темой. Но...
во-первых насколько я помню в VDSP++ есть float для целочисленных процессоров. В чем проблема? На Bf все будет летать и так. Что надо переписывать? Я кода-то с float алгоритмы переносил на fix так и то вспоминать не хочу больше...а если еще самому мутить матлибу - это ошибки человека + ошибки принципиальные - ну как в fix с масштабированием.
во-вторых - насколько я понимаю Linuxовый Speex для bf - целочисленный...и он вполне собираеЦЦо...??? Есть целочисленный вход/выход, в портах для TMS и BF используются типы данных на основе int. ... Что еще надо для души?

Он хочет VBR, jitter buffer и эхоподавитель
А все эксперементальные, недоделаные фичи в SPEEX - float, что в общем-то правильно. Зачем вылизывать алгоритмы, которые ещё десять раз будут переделаны?

Порты BF и TMS int но он их не хочет ;-) В стандартном float32 ни BF ни TMS sPEEX с прибабахами не потянут
Вообще-то float всегда это больше fast prototyping - типа для лохов. Но человек хочет повозиться с прибабахами. Я так понимаю

Быстродействие int на BF я проверял
http://electronix.ru/forum/index.php?showt...36206&st=15
На tms помедленей, упомянуто там же