[one_eight_seven 6]

Вот опять.. у меня крутится... да и на C++ писано...

 

А те же разработчики из ADI приводят примеры проектов сделанные за месяц на С (чтобы быстро показать результат), и потом доведённые до 100% ASMа за год (чтобы работало как надо). Дураки, наверное.

[sigmaN 0]

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

Я вам не скажу за всё Одессу :) Но во время оптимизации Speex под C2000 у меня был подобный опыт. Конечно-же, тут ещё следует добавить, что после asm оптимизации - функция линковалась во внутреннюю память(вместо флэши). Но это, я же говорю, не частое явление. Типичным я бы назвал 2х кратное ускорение.

 

http://electronix.ru/forum/index.php?s=&am...st&p=653411 - реальный пример. Не в 5 раз, конечно. Но и оптимизировалось там выборочно. Ежели ВСЁ переписать - думаю в пять раз можно будет уложить.

Но в том посте я имел ввиду производительность небольшой функции, которая переписывается на асме. И да, были случаи, когда в 5 раз :)

[fontp 0]

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

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

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

 

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

 

А смысл писать TCP-IP на ассемблере да ещё с кольцевыми буферами?

Кольцевые буфера имеют смысл только во внутренних циклах DSP процедур. Использование кольцевых буферов для буферов ввода-вывода почти всегда ничего не даст. AD взял готовый стек LWIP и его портировал. Переписывать его на ассемблер, естественно никто не собирается. Если просто брать и тупо посредством студентов переводить С в ассемблер, то на логической задаче с кучей ветвлений ассемблер скорее всего будет медленней, чем код генерируемый оптимизирующим комилятором С

 

DSP- проекты есть смысл, конечно, оптимизировать кодируя в ассемблер. Но только если не хватает производительности. Оптимизация ради оптимизации никому не нужна. Но расклад здесь примерно такой:

- неграмотно написаный С-код с вызовами функций внутри циклов - в 10-30 раз медленней ассемблера (на ассемблере такое тоже возможно изобразить)

- грамотный С-код на интринсиках - в 3 раза медленней ассемблера

- грамотный С-код на интринсиках с ассемблерной реализацией наиболее критических функций - 2 раза медленней

 

Analog предлагает g729ab для BF c производительностью кодера 7 мипс на ассемблере, но каждый и сам может сделать на 13 мипс на С с совсем небольшими вставками (я делал и потому знаю).

Возникает вопрос нужно ли всегда иметь (500/7)=70 каналов кодера или достаточно будет (500/13)=38.5. Иногда нужно, а иногда - нет ;-))

 

ЗЫ. Это хорошо, если Analog ассемблерную реализацию предлагает бесплатно или за 1$/канал роялти. А если у какого СПИРИТа покупать? Или если самому делать человеко-год?

[777777 0]

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

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

Если я не очень опоздал, то отвечаю на просьбу:

void iir(unsigned short n, short data[], const short k[])
    {
    int x, y, x1=0, x2=0, y1=0, y2=0;
    unsigned short i;
    for(i = 0; i < n; ++i)
        {
        x = data[i];
        y = k[0]*x + k[1]*x1 + k[2]*x2 - k[3]*y1 - k[4]*y2;
        y >>= 14;
        data[i] = (y*k[5])>>14;
        x2 = x1, x1 = x;
        y2 = y1, y1 = y;
        }
    }

Абсолютно тупая и безо всяких оптимизаций реализация фильтра исключительно для проверки его работоспособности (а не для использования в боевой программе). В ассемблере для переменной 'y' использование аккумулятора будет более чем уместно, не так ли?

[jackfrost 0]

На Си врятли можно написать так, чтобы компилятор выда такое:

%VDSP++path%\Blackfin\Examples\Tutorial\fir\fir.asm

С другой стороны написать на ассемблере грамотно тоже нужно понимать что и зачем происходит....

мне например не понятно зачем там NOP в строке комментированной как // Align the instruction

что вообще такое "Align the instruction" ?

[SM 0]

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

Легко. Если в С выключить оптимизацию, включить дебаг и написать специально так, чтобы компилятор не понял, что от него хотят.

 

По общему вопросу - для С-компилеров бывают документы, где рассказано, как правильно код готовить. Вот примеры от TI:

http://focus.ti.com/lit/ug/spru198i/spru198i.pdf

http://focus.ti.com/lit/ug/spru425a/spru425a.pdf

 

найдите аналогичные для вашего процессора и компилятора, и счастье придет.

[vik0 0]

Легко. Если в С выключить оптимизацию, включить дебаг и написать специально так, чтобы компилятор не понял, что от него хотят.

И это понятно. Но речь шла не про "C vs ASM" в общем случае, а про "C optimizer vs ASM".

...Вот примеры от TI...

И от AD:

http://www.analog.com/static/imported-file...160113EE149.pdf

http://www.analog.com/static/imported-file..._transcript.pdf

http://www.analog.com/static/imported-file...kfin_slides.pdf