Используя свой опыт и ваши консультации по вопросам конвертации С++ в С и адаптации программного кода на DSP-платформы, родилась статья...
Прошу вас ознакомиться и выдать свои рекомендации, что вы считаете в ней не корректным, недопустимым, и чего хорошего видите... И помните, что написано в моей подписи

Адрес статьи: КЛИКАЙТЕ СЮДА

Модератор:

Здесь, пожалуйста, обсуждаем только вышеуказанную статью.

Народ, не поленитесь, прочитайте и выскажитесь...

podval, хотт тыы скажи что-нибудь?

ОК.
Если мне не изменяет мой склероз, существует инструментарий разработчика, позволяющий генерить из программы на С++ команды процессоров из семейства Texas Instruments. Там как это все делается?

И вот это впечатляет:

Цитата

Описанная выше методика активно использовалась и давала положительные  результаты  в проектах адаптации программных моделей распознавания и сжатия речи, где основным оптимизационным параметром было время. Результатом вышеописанной методики было ускорение кода более чем в 15 раз на процессорах BlackFin фирмы Analog Devices и десятикратное ускорение на процессоре MCF5249 фирмы Motorola.

Можно подробности о том, где и как это было сделано? Что за фирма, какие разработки?

Цитата

Если мне не изменяет мой склероз, существует инструментарий разработчика, позволяющий генерить из программы на С++ команды процессоров из семейства Texas Instruments. Там как это все делается?

Да, действительно, каждая фирма производитель DSP поставляет вместе со своим железом компиляторы из С++ в ассемблер этого железа.
К примеру,
Analog Devices - Visual DSP++
Motorola - CodeWarrier
TI- не знаю название продукта, но точно есть такая штука...

Помимо этого, есть другие частные фирмы, которые специализируются на выпуске компиляторов (WindRiver и др.).

Но, к сожалению, построить хороший оптимизирующий компилятор для DSP достаточно сложная задача и требует примерно времени от 1 до 2-ух лет, а к этому времени, этот самый DSP уже устаревает и появляются другие процессоры с принципиально другими характеристиками, набором регистров и т.д., которым уже нужен новый компилятор. Вот и приходится выбрасывать на рынок не очень совершенные компиляторы, сырые продукты для отладки... Что крайне негативно сказывается на оптимальность кода...

Посудите сами, как перемножить 2 32-ух разрядных числа на 16-ти разрядном процессоре?
Человек будет мутить примерно такой алгоритм:
1. Выделить младшую и старшую части в первом числе;
2. Выделить младшую и старшую части во втором числе;
3. Перемножать эти кусочки друг на друга;
4. Сложить результаты перемножений этих кусков...
5. Разобраться со знаком резутата, проверить на переполнение, сделать насыщение, если это необходимо...

А как глупенькому компилятору проникнуться в такую штуку ?!

Размер ассемлерного кода для такого умножения, написанного человеком, составляет примерно 50
строчек (в зависимости от типа ассемблера и процессора), а ассемблерный код, который генерирует компилятор для строчек

Код

Word32 a,b,c;                                                    a=b*c

, - 200-250 строк (!) и это не придел для компилятора... А теперь попробуйте фильтровать в реальном времени чей-то "базар" (это я о речи), если так болезненно перемножаются 2 числа... Я уж помолчу про операции с плавующей запятой...
Вот и приходиться выкручиваться...

Цитата

Можно подробности о том, где и как это было сделано?

В самой статьи и изложено комплексная методика так такие штуки вытворять...

Цитата

Можно подробности о том, где и как это было сделано? Что за фирма, какие разработки?

Про разработки на BlackFin(e) могу сказать - это одно из отделений института кибернетики в г. Киеве,
про MCF5249 не могу, в связи с некоторой конфиденциальностью этой информации...

Цитата

Посудите сами, как перемножить 2 32-ух разрядных числа на 16-ти разрядном процессоре?

если компилятор поддерживает эту операцию, то она будет написана так как нужно, потому что эту последовательность команд писали люди, которые делали компилятор
сам компилятор не может придумать кусок кода, он просто заменяет C-шные строки на фрагменты ассемблера...
P.S.
на BlackFin'е это заняло 4 строки, но его нельзя уверенно назвать 16-разрядным процессором
а вот на ADSP это заняло 30 команд (и то, больше половина была для того, чтобы добраться до переменных)

Это сообщение отредактировал(а) maxim1000 - 15.10.2003, 18:29

val
Ты имеешь в виду институт кибернетики им. Глушкова? А сайт есть у него или у этого подразделения?

Цитата

если компилятор поддерживает эту операцию, то она будет написана так как нужно, потому что эту последовательность команд писали люди, которые делали компилятор

Нет, не всегда...

Простой пример из практики... Ассемблерный код расчета скалярного произведения двух векторов сгенерированный компилятором, не отражает особенности DSP архитектуры и не задействует MAC-операции...

Цитата

сам компилятор не может придумать кусок кода, он просто заменяет C-шные строки на фрагменты ассемблера...

Под словом "придумать" нужно понимать наличие встроенных подпрограмм анализа кода, которые не тупо заменяют С-шные строки на ассемблерные, но и осуществляют некоторую оптимизацию выходного ассемблерного кода... Так вот, при такой формулировке компилятор может "придумать" новый кусок кода... Как я уже писал, что в связи с быстрой эволюцией архитектур DSP производители компиляторов не успевают создавать "думающие" компиляторы...

Цитата

Ты имеешь в виду институт кибернетики им. Глушкова?

Так точно...

http://www.icyb.kiev.ua

Но сайт, конечно, тот еще...

Ввиду замечаний, статья изменилась...

Цитата

Простой пример из практики... Ассемблерный код расчета скалярного произведения двух векторов сгенерированный компилятором, не отражает особенности DSP архитектуры и не задействует MAC-операции...

ни один компилятор C не поддерживает такую операцию, как скалярное умножение (по крайней мере, она не входит в стандарт)