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

[Degun]

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

[Degun]

Уважаемый qxov я сделал вашу функцию calcModes с применением DMA. На изображении с разрешением 640*480 пикселей она выполняется за 10.2 мсек.

Код

#include <stdlib.h>
#include <csl_dat.h>

#define IMG_WIDTH  640
#define IMG_HEIGHT 480

// Буферы для кэширования строк изображения
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;

    //Open DAT-chanel
    DAT_open(DAT_CHAANY, DAT_PRI_HIGH, 0);

    //Загрузка первой строки изображения
    Uint32 id_LoadTransfer = DAT_copy(image[0], ModesBuf[0], IMG_WIDTH);
    //Начальная инициализация идентификатора канала сохранения
    Uint32 id_SaveTransfer=DAT_XFRID_WAITNONE;

    //кольцевой указатель на буфер текущей строки
    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;
        //Ожидание окончания загрузки текущей строки изображения
        while(DAT_busy(id_LoadTransfer));
        //Запуск загрузки следующей строки изображения
        id_LoadTransfer = DAT_copy(image[y+1], ModesBuf[iCurrBufIndex], IMG_WIDTH);
        //обработка текущей строки
//#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

            // Здесь получаем, что 4L и 4M юнита - два цикла; еще осталось 4S и 4D, 2D на загрузку
            // уйдет -> остается 4S и 2D юнита, для внутренностей цикла надо 4LSD => останется два S
            // юнита на поддержание цикла. Теоретически, производительность кода - 2 такта на 8 пикселов
            // или 0.25 такта на пиксел. При этом удалось добиться соответствия со значениями мод из
            // оригинального кода, добавив лишь одно ограничение по - количество пикселей должно быть кратно 8.
            // Следует также отметить, что даже при больших размерах изображения, не возникает простоя из-за
            // того, что данные не находятся в кэше.
        }
        //Ожидание окончания сохранения результата
        while(DAT_busy(id_SaveTransfer));
        //Сохранение строки результата
        id_SaveTransfer = DAT_copy(pCurrLineBuf, modes[y], IMG_WIDTH);
    }

    //Ожидание окончания сохранения результата
    while(DAT_busy(id_SaveTransfer));

    //Close DAT-chanel
    DAT_close();
}

Для сравнения неоптимизированный код для того же изображения выполняется за 102 мсек, т. е. оптимизация даёт десятикратный выигрыш.

Код

#include <stdlib.h>

//Функция, классифицирующая пикселы изображения по модам
void SplitImage2Modes(unsigned char ** restrict image, unsigned char ** restrict modes,
    int height, int width, int thresold1, int thresold2)
{
    if ((image==NULL)||(modes==NULL)) return;

    //цикл по всем пикселам изображения
    for(int y=0; y<height; y++) for(int x=0; x<width; x++)
    {
        int pixel=image[y][x];
        if (pixel<thresold1)
            modes[y][x]=0;
        else if (pixel>thresold2)
            modes[y][x]=1;
        else
            modes[y][x]=-1;
    }
}

[qxov]

Уважаемый qxov я сделал вашу функцию calcModes с применением DMA. На изображении с разрешением 640*480 пикселей она выполняется за 10.2 мсек.

Для сравнения неоптимизированный код для того же изображения выполняется за 102 мсек, т. е. оптимизация даёт десятикратный выигрыш.

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