Нужно оптимизировать код, Есть идеи как? Опции

[skyled]

Есть такой кусок кода:

Код

if((pwm>pgm_read_byte(&brightness[pwm_ch[0]]))|(pwm==0)){pd &= ~(1<<0);}//1
        else {pd |= (1<<0);}
        if((pwm>pgm_read_byte(&brightness[pwm_ch[1]]))|(pwm==0)){pd &= ~(1<<1);}//2    
        else {pd |= (1<<1);}
        if((pwm>pgm_read_byte(&brightness[pwm_ch[2]]))|(pwm==0)){pa &= ~(1<<1);}//3
        else {pa |= (1<<1);}
        if((pwm>pgm_read_byte(&brightness[pwm_ch[3]]))|(pwm==0)){pa &= ~(1<<0);}//4
        else {pa |= (1<<0);}
        if((pwm>pgm_read_byte(&brightness[pwm_ch[4]]))|(pwm==0)){pd &= ~(1<<2);}//5
        else {pd |= (1<<2);}
        if((pwm>pgm_read_byte(&brightness[pwm_ch[5]]))|(pwm==0)){pd &= ~(1<<3);}//6
        else {pd |= (1<<3);}
        if((pwm>pgm_read_byte(&brightness[pwm_ch[6]]))|(pwm==0)){pd &= ~(1<<4);}//7
        else {pd |= (1<<4);}
        if((pwm>pgm_read_byte(&brightness[pwm_ch[7]]))|(pwm==0)){pd &= ~(1<<5);}//8
        else {pd |= (1<<5);}
        if((pwm>pgm_read_byte(&brightness[pwm_ch[8]]))|(pwm==0)){pb &= ~(1<<4);}//9
        else {pb |= (1<<4);}
        if((pwm>pgm_read_byte(&brightness[pwm_ch[9]]))|(pwm==0)){pb &= ~(1<<3);}//10
        else {pb |= (1<<3);}
        if((pwm>pgm_read_byte(&brightness[pwm_ch[10]]))|(pwm==0)){pb &= ~(1<<2);}//11
        else {pb |= (1<<2);}
        if((pwm>pgm_read_byte(&brightness[pwm_ch[11]]))|(pwm==0)){pb &= ~(1<<1);}//12
        else {pb |= (1<<1);}
        if((pwm>pgm_read_byte(&brightness[pwm_ch[12]]))|(pwm==0)){pb &= ~(1<<0);}//13
        else {pb |= (1<<0);}
        if((pwm>pgm_read_byte(&brightness[pwm_ch[13]]))|(pwm==0)){pd &= ~(1<<6);}//14
        else {pd |= (1<<6);}

Он обрабатывается за 345 тактов. Мне нужно менее 300. Это возможно? А можно это как-то оформить ассемблерной вставкой? Спасибо.

[_Pasha]

хотите оптимально - пишите на азм-е.
оптимизатор может "оптимизнуть" готовые функции из библиотеки - на 5+, а вот логику - тут уж сильно зависит от опыта того кто писал оптимизатор и за сколько вы его купили.

Поздно! Вот годика 4 назад, когда еще было много проблем с сями, тогда бы это звучало серьезно. Сейчас - увы.

Мама!

Тут выяснилось, что еще вот эта конструкция кушает невообразимое число тактов.

Ара щто ти здэляль со мной? Йа плакаль, перед женщин стидно..

[kolobok0]

...Вот годика 4 назад...

давайте оставим коней в вакууме - пускай отдыхают. если опираться то на факты (посему скорость написания, какчество и прочую чухню - оставим в покое). берём код который народ постит после компиляторов(в азм инструкциях) и от этого пляшем. вы утверждаете что оптимизатор справляется во всех случаях на 5? это хфантастика... как пример - код товарища выше. или Вы чиссо по животным в вакууме специализируетесь?

удачи вам
(круглый)
ЗЫ
всё конечно же зависит от задачи. в своё время приходилось писать и аля шарп технологию под 4051 кристал. но то так было задумано

[_Pasha]

или Вы чиссо по животным в вакууме специализируетесь?

Ну почитайте мои посты, в конце концов. Йа не лублу вакуум.

[defunct]

Ну почитайте мои посты, в конце концов. Йа не лублу вакуум.

Ни один компилятор не даст такой эффективный код, какой может сделать __опытный__ асм программист.
Это аксиома. Неопытному же писать на асм противопоказано - т.к. напишет хуже чем компилятор сделает.
Обработчик прерывания всей той чухни из первого поста на асм занял бы не больше 100 тактов с условием применения регистровых переменных.

[_Pasha]

Ни один компилятор не даст такой эффективный код, какой может сделать __опытный__ асм программист.

Проблема в интенсивном использовании компилятором(winavr) инструкций lds/sts - это раз.
192 такта при -О3(см. в начале темы) - целиком за счет разворачивания цикла. Это два. Там около 490 байт заняло оно, забыл тогда сказать.
Там на регистровые переменные тоже не особо разбежишься - надо использовать ldd/std
А по Вашему предложению - автор если собрался его реализовать, все-таки интересно, во сколько циклов оно встанет.
Извините за словесный понос.

[defunct]

А по Вашему предложению - автор если собрался его реализовать, все-таки интересно, во сколько циклов оно встанет.

Ресурсоемкость кода сократиться в 18 раз только за счет того что прерываний стало в 18 раз меньше, плюс ресурсоемкость самих обработчиков сократится еще в 10 раз за счет того что обрабатываются не все 14, а только 1 канал. Итого на 2 порядка меньше от посчитанных Вами 190 тактов )
На асм писать не предлагаю - здесь нет в этом нужды.

Там на регистровые переменные тоже не особо разбежишься - надо использовать ldd/std

ldd/std определенно пользовать не надо.
Массив 14-ти каналов разместить в регистрах, благо в AVR их аж 16 лишних.
обработчик прерывания банально пишем 5 команд и копипастим 14 раз:

mov - 1 такт
lpm - 3
cp - 1
brlo вместе с cbi/sbi - 2 такта.
Итого на асм 1 + (1 + 3 + 1 + 2) * 14 = 99 тактов решением в лоб. ;>