[ARV 0]

Больше чем в 2 :)

ну, вполне возможно, что и так, я не смотрел листинг. 2 команды среди 4-х - это существенно... но иногда размер имеет большее значение, чем быстрота :)

[_Pasha 0]

Больше чем в 2 :)

Оно и понятно: Надо tmp1 tmp2 в теле do-while объявлять, для начала.

      if (wrtype & 0x02)  
  88:    80 91 02 01     lds    r24, 0x0102
  8c:    81 ff           sbrs    r24, 1
  8e:    08 c0           rjmp    .+16    ; 0xa0 <main+0x34>
            if (wrtype & 0x04)  
  90:    80 91 02 01     lds    r24, 0x0102
  94:    82 ff           sbrs    r24, 2
  96:    02 c0           rjmp    .+4     ; 0x9c <main+0x30>
                tmp1 ^= tmp2;
  98:    92 27           eor    r25, r18
  9a:    06 c0           rjmp    .+12    ; 0xa8 <main+0x3c>
            else
                tmp1 &= tmp2;
  9c:    92 23           and    r25, r18
  9e:    04 c0           rjmp    .+8     ; 0

Тормоза ушли. Можно дальше точить.

ЗЫ мега48, исходный размер около 260 байт, после локализации переменных 216

[ARV 0]

Оно и понятно: Надо tmp1 tmp2 в теле do-while объявлять, для начала.

...

Тормоза ушли. Можно дальше точить.

нет предела совершенству :) в любой программе имеется хотя бы одна ошибка... извините за оффтоп...

[_Pasha 0]

нет предела совершенству :)

Не хвастовства ради, гляньте, что получится при компиляции

int main(void){
while(1){
  uint8_t * pD1 = pD;
  uint8_t * pS1 = pS;
  uint8_t * pB1 = pB;
   do{
   uint8_t tmp1=*pS1++;       
   uint8_t tmp2=*pD1;     
   uint8_t tmp3 = wrtype;

     tmp1 = (tmp3 & 0x02)? 
       ((tmp3 & 0x04)? (tmp1 ^ tmp2):(tmp1 & tmp2))
      :((tmp3 & 0x04)? (tmp1 | tmp2):(tmp1));
    
          *pD1++=tmp1;      
          *pB1++=tmp1;       
     } while(--len); 
   pB = pB1;
   pS = pS1;
   pD = pD1;
       
}}

Исходные те же

Должно получиться: ручной работы асм один в один.

Вывод: как все сложно в работе с глобальными переменными ! :(

[ARV 0]

Не хвастовства ради, гляньте, что получится при компиляции

Исходные те же

Должно получиться: ручной работы асм один в один.

Вывод: как все сложно в работе с глобальными переменными ! :(

а смысл? и так понятно, что по размеру это существенно оптимальнее... а вот сравнить с результатом IAR-а - это интересно, ведь с высказывания, что

И IARу плохеет на таком коде, а gcc делает почти 1 в 1 с асм.

все началось... вот и поглядеть, плохеет ли ему в этом случае, или нет.

[_Pasha 0]

плохеет ли ему в этом случае, или нет.

Три хардовых указателя, как я понял, не поддерживаются иаром, т.к. один из имеющихся указателей используется как указатель стек-фрейма.

[Rst7 5]

Три хардовых указателя, как я понял, не поддерживаются иаром, т.к. один из имеющихся указателей используется как указатель стек-фрейма.

 

Именно. Так что пробовать бестолку. И так могу сказать, что будет.

 

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

[singlskv 0]

Все понятно. Я так и предполагал, что это векторизация, не знал только, что можно отключить.

Ну так для AVR можно сразу выключить эту оптимизацию, потому как нет нативной поддержки в системе комманд. Это будет самая грамотная настройка :)

Вот это одна из причин почему я не перелезаю с gcc3.4.6 на 4.x.x.

Почему-то когда gcc стал переползать на 4.x.x в каждой новой версии свои приколы

и без хорошего знания "спецключиков" и без проверки "а что же получилось..."

работать сложно.

Плохеет. Спору нет.

Теперь давайте я попробую проявить телепатические способности ;)

Приведенный код - это, видимо, разнообразная печаталка символов на графический дисплей? Если да, то имеет смысл развернуть циклы для ускорения, все-таки это самое узкое место в гуйне. А при развороте проигрыша у IAR'а - ну отсилы несколько процентов. Что на общем фоне повышения производительности - так и не заметно.

Не угадали, это обмен по UART или I2C на довольно большой скорости (~350Кбит/c)

в условиях довольно жесткого реалтайма (такт 500 мкс.) и копирование нужно сделать

в пределах 1 такта и еще много чего...

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

А вот другого плана алгоритм - я тут попробовал собрать свою процедуру md5, оптимизированную под AVR... Гнусь сдался по всем параметрам - по размеру кода, по скорости, по требуемому стеку (собственно, взаимосвязь проста - ниасилил разложить все что можно в регистрах, полез в стек и сдался).

Да, бывает что гнусь дуреет на алгоритмах когда нужно много регистров,

ну или на сложной арифметике какой... и тогда нужно бить выражения на части.

Но пример конечно был про то что не всегда он так уж плох, а иногда очень

даже лучше..

 

 

а смысл? и так понятно, что по размеру это существенно оптимальнее... а вот сравнить с результатом IAR-а - это интересно, ведь с высказывания, что все началось... вот и поглядеть, плохеет ли ему в этом случае, или нет.

Господа "оптимизаторы", я по-моему сразу дал понять что разговор о скорости

выполнения при сохранении разумных размеров...

 

Вынос проверок за циклы, вложенные(двоичный поиск) if вместо switch(16бит) итд,

в данном конкретном случае только для достижения скорости.

Ну и конечно все переменные которые участвуют в этом коде локальные.

[ReAl 0]

Кстати, о ключиках.

Вынос проверок за цикл с дублированием тела цикла без проверки для каждой ветви осуществляется ключиком

-funswitch-loops

хотя, конечно, при ручном выносе код получше выходит.