Лишние NOP в ассемблерном коде Опции

[Degun]

Code Composer Studio v 3.3; Процессор DM642 на evalution board.
Имеется программка, написанная на C++. После анализа её ассемблерного кода выяснилось, что после многих команд (LDW, ADD, CMPLT, AND, LDHU и др.) компилятор вставляет команду NOP, что естественно замедляет функционирование программы. Для чего это? Можно ли отключить вставку операторов NOP в ассемблерный код?

[qxov]

А можно ли считать, что за пределами кадра есть рамка размером в один пиксел со значением, скажем, 0?

[Degun]

А можно ли считать, что за пределами кадра есть рамка размером в один пиксел со значением, скажем, 0?

Да вполне.

Скорее всего, простои на ожидание окончания работы DMA + накладные расходы, связанные с DAT модулем. Нужно интегрировать с какими-нибудь другими расчетами - тогда это замедление не будет так сильно сказываться. На глаз раз в 50 сами вычисления быстрее должны производиться, но это - грубо, могу ошибиться, просто спешу сейчас. Но точно сами вычисления значительно быстрее проходят.

Попробовал вариант, в котором убрал все обращения к внешней памяти через DMA, а только к внутреннему static буферу. Этот варинат выполнился за 7.9 мсек. Не понимаю тогда где задержка?

Код

#include <stdlib.h>

#include "cs_common.h"

// Буферы для кэширования строк изображения
static unsigned char ModesBuf[3][IMG_WIDTH];

//Функция, классифицирующая пикселы изображения по модам
void SplitImage2Modes(unsigned char ** restrict image, unsigned char ** restrict modes,
    int thresold1, int thresold2)
{
    //Рабочие регистры цикла
    int lockPixels, compareLo, compareHi, result1, result2;
    unsigned char * restrict pCurrLineBuf;
    double pixels;

    //кольцевой указатель на буфер текущей строки
    int iCurrBufIndex=0;

    //пакеты порогов
    int thresoldLo=_packl4(_pack2(thresold1,thresold1),_pack2(thresold1,thresold1));
    int thresoldHi=_packl4(_pack2(thresold2,thresold2),_pack2(thresold2,thresold2));

    //цикл по всем строкам изображения
//#pragma MUST_ITERATE(IMG_HEIGHT, IMG_HEIGHT);
    for(int y=0; y<IMG_HEIGHT; y++)
    {
        //Указатель на текущую обрабатываемую строку
        pCurrLineBuf = ModesBuf[iCurrBufIndex];
        //Продвижение индекса на следующую строку
        iCurrBufIndex++; iCurrBufIndex%=3;
        //обработка текущей строки
//#pragma MUST_ITERATE(IMG_WIDTH/8, IMG_WIDTH/8);
        for(int x=0; x<IMG_WIDTH; x+=8)
        {
            // Загрузим сразу 8 пикселов
            pixels=_amemd8_const(pCurrLineBuf+x);                  // D

            //Первые четыре пиксела
            lockPixels=_lo(pixels);

            // Если пиксел >= thresold1, то в соответсвующем байте будет 0xff
            compareLo=_xpnd4(_cmpgtu4(lockPixels,thresoldLo));     // L + M

            // Если пиксел >= thresold2, то в соответсвующем байте будет 0xff
            compareHi=_xpnd4(_cmpgtu4(lockPixels,thresoldHi));     // L + M

            // Здесь очень удачно все сложилось - возможны три варианта:
            // если пиксел>=thresold1 и пиксел<thresold2, то получится 0xff ^ 0x00 = 0xff = -1;
            // если пиксел>=thresold1 и пиксел>=thresold2, то получится 0xff ^ 0xfe = 0x01
            // если пиксел<thresold, то пиксел<thresold2 и получается 0x00 ^ 0x00 = 0x00
            result1=compareLo ^ (compareHi & 0xfefefefe);          // LSD + LSD

            // Здесь все тоже самое, для оставшихся четырех пикселов
            lockPixels=_hi(pixels);

            compareLo=_xpnd4(_cmpgtu4(lockPixels,thresoldLo));     // L + M
            compareHi=_xpnd4(_cmpgtu4(lockPixels,thresoldHi));     // L + M

            result2=compareLo ^ (compareHi & 0xfefefefe);          // LSD + LSD

            // Сохраним результат
            _amemd8(pCurrLineBuf+x)=_itod(result2,result1);        // D
        }
    }
}

[qxov]

Да вполне.
Попробовал вариант, в котором убрал все обращения к внешней памяти через DMA, а только к внутреннему static буферу. Этот варинат выполнился за 7.9 мсек. Не понимаю тогда где задержка?

Точно 7.9 мсек?
Просто 7.9 мсек на 500МГц - 3950000 циклов, что многовато для обработки 640*480=307200 пикселов изображения - более 128 циклов на пиксел, а расчетное - около 0.25 с хвостиком должно выходить. Ну пусть в два раза ошиблись, но не на столько же... Оптимизация-то включена?

[Degun]

Точно 7.9 мсек?
Просто 7.9 мсек на 500МГц - 3950000 циклов, что многовато для обработки 640*480=307200 пикселов изображения - более 128 циклов на пиксел, а расчетное - около 0.25 с хвостиком должно выходить. Ну пусть в два раза ошиблись, но не на столько же... Оптимизация-то включена?

Точно 7.9 мсек. Может быть где-то в настройках DSP-BIOS стоит опция размещать статические буфера не в IRAM, а в во внешней SDRAM. Возможно именно из-за этого такое большое время выполнения.