Оптимизация кода IAR С++ v5.10 компилятора, весьма странный код... :( Опции

[sonycman]

Всем привет.
Не даёт покоя один момент в коде программы.
Вкратце - есть прога на С, которую компилирует IAR C/C++ Compiler for AVR
5.10A/W32 (5.10.1.5).
Оптимизация на макс. скорость.
Вот фрагмент сгенерированного кода:

Код

159                  for (a = length; a>0; a--)
   \   00000028   2F01               MOV     R16, R17
    160                  {
    161                      *pBuffer++    =    *text++;
   \                     ??usartSendCommand_4:
   \   0000002A   01F9               MOVW    R31:R30, R19:R18
   \   0000002C   9115               LPM     R17, Z+
   \   0000002E   019F               MOVW    R19:R18, R31:R30
   \   00000030   931D               ST      X+, R17
    162                  }
   \   00000032   950A               DEC     R16
   \   00000034   F7D1               BRNE    ??usartSendCommand_4

Вот думаю, для чего надо выполнять каждую итерацию цикла команды MOVW?
Почему бы не выполнять их один раз перед/после цикла?
Не подскажете, уважаемые, каким образом образумить тупонький компилятор?
А то запарил он повсюду создавать подобную конструкцию...

ЗЫ: вспомнил, что по ИАРу есть отдельная ветка, если нужно, то пусть модераторы перекинут тему туда, извиняюсь...

[Rst7]

Оптимизации, мать их так

Ну попробуйте такой вариант -

Код

#pragma optimize=no_cse
__x bool    usartSendData(const byte    *buffer, byte    length)
{
  byte    a, len;
  if (length > sizeof(tx_buffer) || length == 0)
  {
    statusTx.length_err    =    TRUE;
    return FALSE;
  }
  while (statusTx.length);
  while    ((byte)(sizeof(tx_buffer) - (byte)statusTx.queue) < length);
  len    =    length;
  a = sizeof(tx_buffer) - statusTx.pointer;
  if (length > a)
  {
    byte *p=tx_buffer + statusTx.pointer;
    len -= a;
    for (;a > 0;a--) *p++ = *buffer++;
    statusTx.pointer    =    0;
  }
  statusTx.pointer    +=    len;
  {
    byte *p=tx_buffer + statusTx.pointer;;
    for (;len > 0;len--) *p++ = *buffer++;
  }
  statusTx.length    =    length;
  UCSR0B    |=    1 << UDRIE0;
  statusTx.length_err    =    FALSE;
  return    TRUE;
}

bool    usartSendString(fbyte __flash    *pointer)
{
    return usartSendCommand(USART_TEXT, (const void*)pointer, strlen_P(pointer));
}


#pragma optimize=no_cse
__z bool    usartSendCommand(byte command, const void* pointer, byte length)
{
    byte    a;
    byte    *pBuffer;


    switch (command)
    {
    case    USART_TEXT:
        if (!length || length > USART_MAXDATALENGTH) return FALSE;
        pBuffer    =    comm_buffer + USART_PREFFIX;
        *pBuffer++    =    command;
        *pBuffer++    =    length;

//        copymem_P(pBuffer, (fbyte __flash *)pointer,  length);
    a=length;
    {
      byte *p=pBuffer;
      fbyte    __flash*    text;
      text    =    (fbyte __flash*)pointer;
      do
      {
            *p++    =    *text++;
      }
      while(--a);
      *p=CalculateCRC(pBuffer, length);
    }
        break;
    default:
        return    FALSE;
    }
    pBuffer    =    comm_buffer;
    *pBuffer++    =    'S';
    *pBuffer    =    'N';
    return usartSendData(comm_buffer, length + USART_FRONTEND);
}

Тут много магии - отдельные указатели (почему-то иногда очень плохо у IAR'а по ходу выполнения функции переменные перемещаются по регистрам), no_cse... А в общем итоге видимо проблема заключается в том, что использование структур и двух указателей сразу приводит к нехватке регистровых пар. Видимо, тут GCC был бы на высоте.

Обработчики прерываний (в виде единой функции!) с длиннющим сохранением регистров на стёк, когда на асме обошёлся бы парой-тройкой...

Если какие-то функции другие вызываются - будет сохранение всех scratch-регистров, если нет - все будет хорошо.

Вот зачем надо было вводить второй стёк для данных?

Вот GCC не делает второй стек для данных. Все хорошо, пока переменные одной функции помещаются в регистрах. Как только надо исполнить стековую переменную - начинается мрак, там такой код для пролога/эпилога, что с непривычки за голову хватаешься...

Тут конечно, надо бы было сделать 2 комманды при разработке ядра, LDD r,SP+disp и STD SP+disp,r и пару комманд увеличения/уменьшения указателя стека - и тогда бы здорово помогло... Но поезд ушел 10 лет назад

[singlskv]

Тут много магии - отдельные указатели (почему-то иногда очень плохо у IAR'а по ходу выполнения функции переменные перемещаются по регистрам), no_cse... А в общем итоге видимо проблема заключается в том, что использование структур и двух указателей сразу приводит к нехватке регистровых пар. Видимо, тут GCC был бы на высоте.

О, это именно то о чем я твержу уже очень давно но все почему-то относятся к этому
скептически, IAR действительно дуреет когда количество источников/приемников данных
в близлежащем коде >2, причем обращение к структурам у него часто идет как обращение
к источнику/приемнику данных. При этом выбор того что будет адресоваться через регистровую
пару зависит от порядка обращения в исходнике. У Gcc с этим чуть по лучше, правда, если уж
совсем по-честному, иногда лишние movw тоже бывают, но лечится обычно просто заведением локальных указателей без всяких прагм.