[777777 0]

Пишу программу в VidualDSP 5.0 для BF537. Все получается хорошо, компилятор довольно эффективный, но складывается впечатление, что он пользуется исключительно регистрами R и P и ничего не знает о существовании аккумуляторов, barrel shifter-ов, индексных регистров и т.п. Можно ли как-то заставить его использовать их для вычислений типа y[n] = k1*x[n] + k2*y[n-1] + k3*y[n-2] + ..., или придется эту часть писать на ассемблере?

[DRUID3 0]

... ничего не знает о существовании аккумуляторов, barrel shifter-ов...

??? А Вы их как пишите?

[777777 0]

??? А Вы их как пишите?

Кого "их"? Аккумуляторы? Никак, я пишу программу на Си и наивно надеюсь, что если компилятор увидит код, который можно эффективно выполнить с использованием аккумуляторов, то он будет их использовать. Я, правда, не представляю, насколько умным должен быть компилятор, чтобы увидеть это, но ведь прогресс на месте не стоит. Или таки стоит? И Си можно использовать только для простейших работ (инициализацию, пересылку данных), а основную часть делать на ассемблере?

[sigmaN 0]

Ну не знаю как там на BF у Вас дела обстоят, но по опыту техасовского C2000 могу сказать, что грамотно оптимизированный asm код - порой уделывает Сишный по скорости раз в 5 (ну это тяжелый случай, конечно, но было дело пару раз) :) Я уже не говорю о размере кода.

Хотя, просматривая листинги я не могу сказать, что я заметил, чтобы что-то он там не использовал. Все регистры, всё использует.

Но увидеть нужные закономерности в коде, убрать всё лишнее, используя особенности pipeline по вставлять полезные команды вместо NOP - это у него не всегда получается.

Хотя при максимальной оптимизации - видно даже как он старается :)

Кстати, да, а как насчёт оптимизаций? Они включены у Вас?

А ещё каждый компилятор имеет свои заморочки и чего-то он любит, а чего-то не любит. Нужно, чтобы программер и компилер привыкли друг к другу :)

 

Но всё равно, если реально нужна эффективность - без ассемблера не выкрутишься. Стандартным значением в DSP задачах можно назвать 2х кратное увеличение скорости выполнения.

Ещё одним плюсом есть то, что написанный на асме код - всегда компактнее. Особенно, когда внутренней памяти начинает не хватать...

[777777 0]

что грамотно оптимизированный asm код - порой уделывает Сишный по скорости раз в 5 (ну это тяжелый случай, конечно, но было дело пару раз) :)

Это не опечатка? Кто кого уделывает?

 

Кстати, да, а как насчёт оптимизаций? Они включены у Вас?

Разумеется.

 

А ещё каждый компилятор имеет свои заморочки и чего-то он любит, а чего-то не любит. Нужно, чтобы программер и компилер привыкли друг к другу :)

Вот это я и пытаюсь сделать. :)

[DRUID3 0]

Кого "их"? Аккумуляторы? Никак, я пишу программу на Си и наивно надеюсь, что если компилятор увидит код, который можно эффективно выполнить с использованием аккумуляторов, то он будет их использовать.

...можно пример Вашего кода, где именно Вы считаете к месту использование аккумулятора... Тот же FIR. Что-то мне подсказывает, что не в компиляторе дело :rolleyes: . И тип данных какой?

 

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

Х.з. я вообще уже забыл как VDSP выглядит. :rolleyes:

 

И Си можно использовать только для простейших работ (инициализацию, пересылку данных), а основную часть делать на ассемблере?

Use the Force, Luke. Let go, Luke. Luke, trust me.

А если серьезнее, то основную часть на asm уже сделали наши братья из Индии. Что Вам там не нравится? Инициализацию на C для bf - это, как говорится, нужно увидеть :) . Да и пересылку (??? SPORT->DMA->SDRAM???) интересно глянуть . Логичнее писать на C main()+хидеры :) , а вызываемые процедуры на asm. Причем нужно еще постараться чтобы не найти готовых, которые надо только чуток подправить.

 

C-код, например, удобен, как всегда тем, что он кроссплатформенен, можно перетянуть совершенно с другой архитектуры проект. Но компилятор никогда не узнает сам, подсунь Вы ему то же FFT для int, что тут вот нужно включить аппаратный битреверс, а тут нужно масштабировать коэффициенты и т.д.; DSP фичи - это нужно "руками"...

[andrewn 0]

придется писать на ассемблере?

Часто бывает достаточно использовать intrinsics (sect 8.2.3 и

вся глава 8):

Embedded Signal Processing with the Micro Signal Architecture. Woon-Seng Gan, Sen M. Kuo. Wiley-IEEE Press,

preview:

http://books.google.com/books?id=1TM9jBBU2...;q=&f=false

d/l:

http://www.automationlabs.ru/forum/showthr...1672&page=5

[fontp 0]

Да, нужно использовать интринсики, в частности библиотеку ETSI.

#define ETSI_SOURCE

#define ADI_FAST_ETSI

#include <libetsi.h>

 

 

Фильр - это в цикле

 

sumFIR = L_mac(sumFIR,*bp++,*hp++);

 

При желании bp или hp можно средствами С даже сделать циклическим и разнести по разным банкам памяти.

Однако VisualDSP++ не жалует I-регистры и не умеет оптимизировать использование банков памяти.

[evg123 0]

В техасовских DSP (2000, 5000, 6000 ) фильтры реализованы - все на ассемблере. А из C - вызываются стандартные функции. У вас должно быть то же самое.

Самому писать фильтр используя intrisic - вызовы - не знаю... Для dsPIC-ов мы такое делали (по прилагаемым примерам), а у таких вещей как BF !должны! быть оптимизированные библиотеки с фильтрами, FFT и прочими стандартными функциями обработки сигналов. А чтобы компилятор сам распознавал, что вы программируете фильтр и тут же вставлял для него код - это такое есть наверное только в Квартусе под Циклон. Там он распознаёт VHDL или Verilog код и вставляет аппаратные MAC-мегафункции. Но это из другой оперы.

[sigmaN 0]

что грамотно оптимизированный asm код - порой уделывает Сишный по скорости раз в 5 (ну это тяжелый случай, конечно, но было дело пару раз) smile.gif

 

Это не опечатка? Кто кого уделывает?

Ну да. Тут естественно имелось ввиду то, что asm код быстрее и меньше по объёму, чем сишный.

[vik0 0]

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

Присоединяюсь к просьбе.

Инициализацию на C для bf - это, как говорится, нужно увидеть :) . Да и пересылку (??? SPORT->DMA->SDRAM???) интересно глянуть .

??? Может я не правильно понял, но чем вам не нравится инициализация фина на С (разве что вы имеете ввиду initcode...Хотя даже там можно использовать С.. В 54х серии к примеру ;) )? И какие проблемы с оргнизацией пересылки SPORT->DMA->SDRAM на С? Поясните свою мысль, пожалуйста.

Логичнее писать на C main()+хидеры :) , а вызываемые процедуры на asm.

Очень спорное утверждение.

Причем нужно еще постараться чтобы не найти готовых, которые надо только чуток подправить.

Угу. Мечтаю увидеть реализацию на asm-е TCP/IP стека под 537-й.

В техасовских DSP (2000, 5000, 6000 ) фильтры реализованы - все на ассемблере. А из C - вызываются стандартные функции. У вас должно быть то же самое.

Есть, они, есть. Индусские, но работоспособные. И достаточно оптимальные.

Ну да. Тут естественно имелось ввиду то, что asm код быстрее и меньше по объёму, чем сишный.

Нет, это понятно. Но в ПЯТЬ раз?

[one_eight_seven 6]

Ребята, почитал вас и удивился...

Интринсики, Си... всё это хорошо... Но ведь тут вы лезете в DSP - область, в которой С всегда испльзуется только что бы быстро получить какой-то результат. Конечный результат всегда достигается в ассемблере. Это вам не МК, не приложение с GUI, и не ползовательская программа под Windows или любой другой операционкой на PC или MAC. Поэтому вопросы: "как заставить Си всё делать правильно",- звучат странно. В любом случае, это выйдет во много раз дольше, чем, оптимизация кода. Поэтому, делайте прямые ассемблерные вствки в критичных местах, и будет вам счастье.

[Andron_ 0]

на C55xx пытался использовать instrincts... код получается абсолютно нечитабельным, а по скорости асмовскому на КИХ-фильтрации все равно проигрывает...

[vik0 0]

Ребята, почитал вас и удивился...

Интринсики, Си... всё это хорошо... Но ведь тут вы лезете в DSP - область, в которой С всегда испльзуется только что бы быстро получить какой-то результат. Конечный результат всегда достигается в ассемблере. Это вам не МК, не приложение с GUI, и не ползовательская программа под Windows или любой другой операционкой на PC или MAC. Поэтому вопросы: "как заставить Си всё делать правильно",- звучат странно. В любом случае, это выйдет во много раз дольше, чем, оптимизация кода. Поэтому, делайте прямые ассемблерные вствки в критичных местах, и будет вам счастье.

Простите, вы вообще с blackfin-ами работали? Это ведь не "чистый" dsp. На нем, помимо собственно dsp алгоритмов может крутится еще много чего (тоже самое GUI, к примеру).

Из личного опыта - на 537-м (тот же самый, что и у топикстартера) крутятся достаточно ресурсоемкие вычислительные алгоритмы плюс RTOS, TCP/IP стек (100 MBit ethernet), CANOpen slave и "недо"-GUI (на PAL видеовыход :07: + PS/2 клава). Все написано на С++. В пике процессор занят на 75-80%.

[DRUID3 0]

??? Может я не правильно понял, но чем вам не нравится инициализация фина на С (разве что вы имеете ввиду initcode...Хотя даже там можно использовать С.. В 54х серии к примеру ;) )? И какие проблемы с оргнизацией пересылки SPORT->DMA->SDRAM на С? Поясните свою мысль, пожалуйста.

А что там реально от языка C? Вот я о чем...

 

Очень спорное утверждение.

Уточняю - DSP-процедуры. Причем процедуры-то всего-навсего - немножечко доковырять, если что-то не устраивает...

 

Угу. Мечтаю увидеть реализацию на asm-е TCP/IP стека под 537-й.

Первоначально речь идет, повторюсь, о DSP-автоматах которые не хочет использовать C-компилятор "по-назначению".

Программы для процессоров общего назначения на DSP - это как раз из серии "что можно "стянуть" имея C-компилятор".

TCP/IP довольно большой проект, я сомневаюсь, что AD его сами с нуля писали, скорее ковыряли какие-то BSD+студентческий или предыдущий опыт разработчиков - потому и C. Но, кстати, не значит же это что его нельзя на bf asm написать, с этим справится любой программист на бесконечном интервале времени .

 

P.S.: кстати в том же IP-TCP часто должна возникать потребность в кольцевой адресации(понятно, что аппаратно - выгоднее), интересно это как-то используют?

 

добавил...

Простите, вы вообще с blackfin-ами работали? Это ведь не "чистый" dsp. На нем, помимо собственно dsp алгоритмов может крутится еще много чего (тоже самое GUI, к примеру).

Из личного опыта - на 537-м (тот же самый, что и у топикстартера) крутятся достаточно ресурсоемкие вычислительные алгоритмы плюс RTOS, TCP/IP стек (100 MBit ethernet), CANOpen slave и "недо"-GUI (на PAL видеовыход :07: + PS/2 клава). Все написано на С++. В пике процессор занят на 75-80%.

Вы опять за свое. У меня вообще 99.9% на C из всех уголков земного шарика, только немножечко индусского кода оформлено в виде отдельной либы самой AD. Но этот код не задействует аппаратные возможности DSP-расширений сам по себе... Вот о чем вопрошал автор ветки...

 

Тот же ffmpeg вручную доводили до состояния оптимальности для bf. Компилятор сам этого не сделает.