[mantech 7]

Приветствую.

Не буду грузить, насколько бесят меня все эти разницы в синтаксисах различных компиляторов, но это факт.

Может кто подскажет, чего ИАР ругается на строчку BGT NEONCopyPLD ?

Функция написана под ГЦЦ.

void my_copy(volatile unsigned char *dst, volatile unsigned char *src, int sz)
{
       if (sz & 63) {
           sz = (sz & -64) + 64;
       }
       asm volatile (
           "NEONCopyPLD:                          \n"
           "    VLDM %[src]!,{d0-d7}                 \n"
           "    VSTM %[dst]!,{d0-d7}                 \n"
           "    SUBS %[sz],%[sz],#0x40                 \n"
           "    BGT NEONCopyPLD                  \n"
           : [dst]"+r"(dst), [src]"+r"(src), [sz]"+r"(sz) : : "d0", "d1", "d2", "d3", "d4", "d5", "d6", "d7", "cc", "memory");
}

 

Edited July 27, 2020 by mantech

[jcxz 52]

49 минут назад, mantech сказал:

Может кто подскажет, чего ИАР ругается на строчку BGT NEONCopyPLD ?

Текст "ругательства" и версию IAR-а видимо предлагаете угадать читателю, используя телепатические способности?  

[mantech 7]

49 минут назад, jcxz сказал:

Текст "ругательства" и версию IAR-а 

Понял...

Error[Og010]: Inline assembler instruction does not have a unique size: "        BGT   ??NEONCopyPLD"

Версия 6.50 АРМ

[jcxz 52]

43 минуты назад, mantech сказал:

Error[Og010]: Inline assembler instruction does not have a unique size: "        BGT   ??NEONCopyPLD"

Версия 6.50 АРМ

Такого старья не имею - не проверить. Но может попробовать явно указать размер инструкции перехода (раз он что-то талдычит про её размер)?

Типа: " BGT.N  NEONCopyPLD"

Мой IAR_7.80.4 сам умеет выбирать оптимальный размер, но может старый 6.50 не умел?

 

PS: А зачем таким старьём пользуетесь, а не обновите до 7.80.4 хотя-бы?

[mantech 7]

3 часа назад, jcxz сказал:

PS: А зачем таким старьём пользуетесь, а не обновите до 7.80.4 хотя-бы?

Хороший вопрос, на который всегда отвечаю, зачем обновлять что-то, что нормально работает...

3 часа назад, jcxz сказал:

Типа: " BGT.N  NEONCopyPLD"

Попробую, спасибо.

[jcxz 52]

1 час назад, mantech сказал:

Хороший вопрос, на который всегда отвечаю, зачем обновлять что-то, что нормально работает...

Нормально? А вот 7.80.4 нормально компилит " BGT ..."  

К тому-же, насколько помню, в версии 6.чего_то_там был серьёзный баг в работе компилятора. Обсуждали его в своё время на форуме.

[mantech 7]

15 часов назад, jcxz сказал:

К тому-же, насколько помню, в версии 6.чего_то_там был серьёзный баг в работе компилятора.

Вот этого не помню, но было такое, что обсуждали при переходе с 6хх на 7хх у людей все вставало колом - вот такого хочу избежать у себя...

Тем более, проекты на ИАРе все уже закрыты, только для исправления ошибок, поэтому не вижу смысла вообще. Ну а с этим - А вот 7.80.4 нормально компилит " BGT ..."   -  даже если и так, то ради одной строчки тоже нет смысла, ИМХО.

Edited July 28, 2020 by mantech

[__inline__ 0]

23 hours ago, mantech said:

"NEONCopyPLD:                          \n"
           "    VLDM %[src]!,{d0-d7}                 \n"
           "    VSTM %[dst]!,{d0-d7}                 \n"
           "    SUBS %[sz],%[sz],#0x40                 \n"
           "    BGT NEONCopyPLD                  \n"

 

Смею предположить, что ругается из-за метки. Попробуйте заменить везде NEONCopyPLD  на 1b.

 

P.S. IAR - редкостная параша.  От себя добавлю: не поддерживает локальные метки, что бывает очень необходимо при разворачиванию макросов.  Ох да!!! ТРУЪ-"эмбиддеры" сейчас набегут и закидают шапками - что либо код корявый или можно обойтись без меток.... Вот и обходитесь сами без них,  а мне оно нужно! Поэтому GCC - нашё всё!

Edited July 28, 2020 by __inline__

[mantech 7]

27.07.2020 в 22:04, mantech сказал:

Хороший вопрос, на который всегда отвечаю, зачем обновлять что-то, что нормально работает...

Попробую, спасибо.

Вообщем все это заработало, скомпилировалось, но появилась очередная шляпа

Вот сделал функцию рисования прямоугольника:

void NEON_FillRect64(uint32_t *img_src,uint16_t x,uint16_t y,uint16_t xc,uint16_t yc,uint32_t c)
{
  uint32_t *src= (uint32_t*)DEV_PXP_BASE; //временный буфер в памяти
  uint32_t *video=img_src;
  int32_t size,i; 
  
  
  for (i = 0; i < 16; i++) *src++=c; //заполняем константой цвета 64 байта
  src= (uint32_t*)DEV_PXP_BASE;
  asm volatile (
            "VLDM %[src]!,{d0-d7}\n" 
              : [src]"+r"(src) : : "d0", "d1", "d2", "d3", "d4", "d5", "d6", "d7", "cc", "memory"
              );
  
  while (y<yc+1)
     {
       video = img_src+(x+(y*PhyX_MAX));
       size=(xc-x)<<2;
       if (size & 63) {size = (size & -64) + 64;}
       asm volatile 
           (
            "NEONCopyPLD:\n"
            "VSTM %[video]!,{d0-d7}\n"
            "SUBS %[size],%[size],#0x40\n"
            "BGT.N   NEONCopyPLD\n"
            : [video]"+r"(video),  [size]"+r"(size) : : "d0", "d1", "d2", "d3", "d4", "d5", "d6", "d7", "cc", "memory"
           );
       y++;
     }
    
}

Рисует, но если выполнить 2 этих функции подряд с разным цветом заполнения, то вторая заполняет тем же цветом, такое впечатление, что первая положила данные регистров в "кэш" и вторая уже берет оттуда, а не новые даные. Если это так, то как можно его сбросить?

[jcxz 52]

2 часа назад, mantech сказал:

size=(xc-x)<<2;

if (size & 63) {size = (size & -64) + 64;}

проще: size = (xc - x - 1 | 15) + 1 << 2;

[mantech 7]

5 минут назад, jcxz сказал:

проще: size = (xc - x - 1 | 15) + 1 << 2;

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

[jcxz 52]

2 часа назад, mantech сказал:

Рисует, но если выполнить 2 этих функции подряд с разным цветом заполнения, то вторая заполняет тем же цветом, такое впечатление, что первая положила данные регистров в "кэш" и вторая уже берет оттуда, а не новые даные. Если это так, то как можно его сбросить?

А листинг в порядке? Проверили?

[haker_fox 19]

8 minutes ago, jcxz said:

проще: size = (xc - x - 1 | 15) + 1 << 2;

Как вы такие красивые оптимизации выводите, научите, пожалуйста)

[mantech 7]

2 минуты назад, jcxz сказал:

А листинг в порядке? Проверили?

Ничего криминального не заметил. Еще один момент, сделал такой же рисовальщик но не по 64 байта, а по 32. Т.е. задействованы регистры D0-D3. Так вот если сначала рисуешь 64й, а потом 32й, то все рисует норм, а если только 64ми то тупит..

[jcxz 52]

2 часа назад, mantech сказал:

Ничего криминального не заметил. Еще один момент, сделал такой же рисовальщик но не по 64 байта, а по 32. Т.е. задействованы регистры D0-D3. Так вот если сначала рисуешь 64й, а потом 32й, то все рисует норм, а если только 64ми то тупит..

А если по шагам пройти? Нормально рисует?

Я NEON-ами не занимался - не шарю в них, но раз используете регистры FPU, я бы ещё проверил - нет ли косяков с этими регистрами при переключениях контекста? Если где-то контекст FPU не сохраняется/восстанавливается, то некоторые регистры будут порушены. Так что можно проверить отрисовку при запрещённых прерываниях.

2 часа назад, haker_fox сказал:

Как вы такие красивые оптимизации выводите, научите, пожалуйста)

Ну ведь про округление до степени двойки при помощи AND все знают? Так OR - это то же самое, но для инверсных данных (ну и естественно - не вниз, а вверх).