Несимметрия конечного результата vinavr компилятора Опции

[=GM=]

Всем привет.
Такой вопрос. Почему код

Код

  while(pph!=&ph[8])
  {
   *(pph++)=~(*(pph-4));
  },

в котором берётся часть массива, инвертируется и записывается в другое место, компилируется в такой несимметричный код?

Код

  while(pph!=&ph[8])
  {
   *(pph++)=~(*(pph-4));
  94:    fd 01           movw    r30, r26
  96:    34 97           sbiw    r30, 0x04; 4
  98:    80 81           ld    r24, Z
  9a:    80 95           com    r24
  9c:    8c 93           st    X, r24
  9e:    80 91 71 00     lds    r24, 0x0071
  a2:    80 95           com    r24
  a4:    11 96           adiw    r26, 0x01; 1
  a6:    8c 93           st    X, r24
  a8:    11 97           sbiw    r26, 0x01; 1
  aa:    90 91 72 00     lds    r25, 0x0072
  ae:    89 2f           mov    r24, r25
  b0:    80 95           com    r24
  b2:    12 96           adiw    r26, 0x02; 2
  b4:    8c 93           st    X, r24
  b6:    12 97           sbiw    r26, 0x02; 2
  b8:    80 91 73 00     lds    r24, 0x0073
  bc:    80 95           com    r24
  be:    13 96           adiw    r26, 0x03; 3
  c0:    8c 93           st    X, r24
  }

Казалось бы чего проще, для всех 4-х байт сделать одно и тоже действие: загрузить байт
в регистр, а лучше бы воспользоваться регистровой парой Z, инвертировать и записать в
новое место, указываемое парой Х. Дальше, почему бы не использовать постинкремент Х+
вместо двух команд adiw и st? Может, кто-то знает, как переделать си-код в нечто подобное?

[demiurg_spb]

Мне вообще представленная ТС строка не нравится

*(pph++)=~(*(pph-4));

приходится напрягать мозг чтобы понять что произойдёт тут и вспоминать точки следования
ИМХО так значительно прозрачнее

Код

pph[0] = ~pph[-4];
pph++;

ну или даже так

Код

*pph++ = ~pph[-4]

не, так плохо, прогнал, и на компиляции получил предупреждение о возможном неопределённом поведении. {дополнено позже}

при грамотном использовании инлайн-асм gcc позволяет сделать практичеки чудеса

Это наверно так, но у меня к примеру почему-то простейшая конструкция не выходит (правда я нашёл другой способ решить мою задачу)

Код

#define makeword16(b0,b1)                                                     \
(__extension__({                                                              \
    uint8_t  __b0 = (uint8_t)(b0);                                            \
    uint8_t  __b1 = (uint8_t)(b1);                                            \
    uint16_t __result;                                                        \
    __asm__ __volatile__                                                      \
    (                                                                         \
        "\n\t"                                                                \
        "mov %A0,%A1"                       "\n\t"                            \
        "mov %B0,%A2"                       "\n\t"                            \
        : "=r" (__result)                   /* output operands */             \
        : "r" (__b0),                       /* input operands */              \
          "r" (__b1)                                                          \
    );                                                                        \
    __result;                                                                 \
}))

uint8_t b[n];
uint16_t x = makeword16(b[1],b[0]); //read big-endian value
...

получаем

Код

     582:    81 81           ldd    r24, Z+1; 0x01
     584:    90 81           ld    r25, Z
     586:    88 2f           mov    r24, r24     // я плакал:(
     588:    99 2f           mov    r25, r25     // дважды:(

Если вы сможете мне помочь буду очень благодарен за развитие кругозора. Спасибо!

[=GM=]

1) Мне вообще представленная ТС строка не нравится *(pph++)=~(*(pph-4));

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

2) ИМХО так значительно прозрачнее

Код

pph[0] = ~pph[-4];
pph++;

Моя версия компилятора даёт один и тот же ассемблерный код для обоих вариантов 1 и 2.

while(pph!=&ph[8])
{
*(pph++)=~(*(pph-4));
98: 80 91 70 00 lds r24, 0x0070
9c: 80 95 com r24
9e: 80 93 74 00 sts 0x0074, r24
a2: 80 91 71 00 lds r24, 0x0071
a6: 80 95 com r24
a8: 80 93 75 00 sts 0x0075, r24
ac: 80 91 72 00 lds r24, 0x0072
b0: 80 95 com r24
b2: 80 93 76 00 sts 0x0076, r24
b6: 80 91 73 00 lds r24, 0x0073
ba: 80 95 com r24
bc: 80 93 77 00 sts 0x0077, r24

И сначала мне больше понравилась ваша версия 2, поскольку никаких предупреждений не было, а в моём варианте было предупреждение: operation on pph may be undefined - операция с pph может быть неопределенной.

Но присмотревшись к коду, я понял к чему относится предупреждение. По си коду указатель pph в процессе исполнения кода увеличивается на 4, а в листинге указатель кода никак не участвует, поскольку там цикл развернут и применена прямая адресация! Поэтому компилятор предупреждает, что если вы будете использовать pph дальше, то содержимое указателя может быть отлично от того, на что вы рассчитывали. Я считаю, что лучше пусть будет предупреждение просто как напоминание, что может произойти в дальнейшем.

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

int main(void) //LCD test
{
unsigned char *pph;
unsigned char *pdg;
while(1)
{
pdg=&dig[0];
pph=&ph[4];
while(pph!=&ph[8])
{
*(pph++)=~(*(pph-4));
}
}
}

получается такой ассемблерный листинг

int main(void) //LCD test
{
5e: e4 e7 ldi r30, 0x74 ; 116
60: f0 e0 ldi r31, 0x00 ; 0
pph=&ph[4];
while(pph!=&ph[8])
{
*(pph++)=~(*(pph-4));
62: 34 97 sbiw r30, 0x04 ; 4
64: 80 81 ld r24, Z
66: 34 96 adiw r30, 0x04 ; 4
68: 80 95 com r24
6a: 81 93 st Z+, r24
}
while((pdg)!=&dig[4]);
pph=&ph[4];
while(pph!=&ph[8])
6c: 80 e0 ldi r24, 0x00 ; 0
6e: e8 37 cpi r30, 0x78 ; 120
70: f8 07 cpc r31, r24
72: b9 f7 brne .-18 ; 0x62 <main+0x4>
74: 34 97 sbiw r30, 0x04 ; 4
76: f5 cf rjmp .-22 ; 0x62 <main+0x4>

Умереть-не встать: теперь компилятор решил не разворачивать цикл while. Не могу понять, по какой причине меняется генерируемый код - по воле левой ноги компилятора или я делаю что-то не так?