Никак не обмануть gcc 4.1.2 Опции

[demiurg_spb]

Пытаюсь оптимизировать процедуру очистки дисплея, но gcc не поддаётся дрессуре
Оптимизация: Os.

Код

#define LCD_WIDTH             128U
#define LCD_HEIGHT            64U
#define LCD_STR_HEIGHT     8U

unsigned char lcd_vram[LCD_WIDTH][LCD_HEIGHT/LCD_STR_HEIGHT];    // Буфер видеопамяти LCD.

//====================================
void lcd_clrscr(void)
{
    unsigned char*p = &lcd_vram[0][0];

#if (((LCD_WIDTH*LCD_HEIGHT/LCD_STR_HEIGHT)/8)>255)
# error "(sizeof(lcd_vram)/8)>255 !!!"
#endif

    register unsigned char i = sizeof(lcd_vram)/8;
    do
    {
        *p++ = 0; // 1
        *p++ = 0; // 2
        *p++ = 0; // 3
        *p++ = 0; // 4
        *p++ = 0; // 5
        *p++ = 0; // 6
        *p++ = 0; // 7
        *p++ = 0; // 8
    }
    while (--i);
}

Получаю листинг такого вида:

Код

lcd_clrscr:
        ldi r30,lo8(lcd_vram)
        ldi r31,hi8(lcd_vram)
.L2:  
        st Z,__zero_reg__
        std Z+1,__zero_reg__
        std Z+2,__zero_reg__
        std Z+3,__zero_reg__
        std Z+4,__zero_reg__
        std Z+5,__zero_reg__
        std Z+6,__zero_reg__
        std Z+7,__zero_reg__
        adiw r30,8
        ldi r24,hi8(lcd_vram+1024)
        cpi r30,lo8(lcd_vram+1024)
        cpc r31,r24
        brne .L2
        ret

Мне никак не удаётся заставить gcc использовать однобайтный счётчик цикла, отказаться от adiw и использовать st+,__zero_reg__. Так код стал бы и короче и быстрее...

И попутно вопрос №2:
Я считал, что static const является альтернативой define.
Но, видимо, я заблуждался...

Код

static const unsigned char MY_ARRAY_SIZE = 2;
//#define MY_ARRAY_SIZE 2

unsigned char my_array[MY_ARRAY_SIZE] = {0,0};

получаю сообщение:
../../../arclib/common/lcd128x64.c:10: error: variably modified 'my_array' at file scope
../../../arclib/common/lcd128x64.c:10: warning: excess elements in array initializer
../../../arclib/common/lcd128x64.c:10: warning: (near initialization for 'my_array')

А если через #define MY_ARRAY_SIZE 2 - то всё ок.

Знающие люди, объясните такое поведение.
Спасибо!

[_Pasha]

Только что глянул код и листинг еще раз, и увидел:
оптимизатор исключил переменную i, воспользовавшись ZL:ZH как регистром базы и, однвременно, переменной цикла. А если так, то все попытки ввести "дрессурой" перем. цикла в явном виде, порождают менее эффективный код. Вывод : ни о чем беспокоиться не надо. Компилер сделал правильно.

[AHTOXA]

все попытки ввести "дрессурой" перем. цикла в явном виде, порождают менее эффективный код.

А из моего асмового варианта получилось:

Код

    278c:    80 e8           ldi    r24, 0x80; 128
    278e:    e7 e6           ldi    r30, 0x67; 103
    2790:    f0 e0           ldi    r31, 0x00; 0

00002792 <L_22>:
    2792:    11 92           st    Z+, r1
    2794:    11 92           st    Z+, r1
    2796:    11 92           st    Z+, r1
    2798:    11 92           st    Z+, r1
    279a:    11 92           st    Z+, r1
    279c:    11 92           st    Z+, r1
    279e:    11 92           st    Z+, r1
    27a0:    11 92           st    Z+, r1
    27a2:    81 50           subi    r24, 0x01; 1
    27a4:    b1 f7           brne    .-20     ; 0x2792 <L_22>

Это менее эффективно?

[_Pasha]

Это менее эффективно?

А Вы посчитайте - если не ошибаюсь, Вы выиграли 2 такта и/или 3 слова программ.
Зачем полировать то, что может быть гораздо шершавее ?
Другой вопрос, что на сях корявенько - через switch(lcd_state){...} состояния делаются, на асме через упрощенную кооперативную многопоточность куда проще и даже читабельнее, но это оффтоп.

[demiurg_spb]

А Вы посчитайте - если не ошибаюсь, Вы выиграли 2 такта и/или 3 слова программ.

Выигрыш 3 такта и 3 слова, т.к. adiw выполняется за 2 такта.
Итог для этого случая 128*3=384 такта,
а если циклов 256, то 768 тактов....

Зачем полировать то, что может быть гораздо шершавее ?

А действительно, зачем вообще что-либо делать?
Ведь можно продолжать смотреть диафильмы на проекторе с ручным приводом,
а DVD и HDTV - это не для нас, потому что мы не в состоянии поднять FPS...
Когда компилятор считает себя умнее программиста - это немного раздражает...

[aesok]

Выигрыш 3 такта и 3 слова, т.к. adiw выполняется за 2 такта.
Итог для этого случая 128*3=384 такта,

Допустим что фрейм буфер очищается 25 раз в секунду, это значит что выигрыш
25 * 384 = 9600 тактов в секунду, или примерно 0.1% при тактовой частоте 10МГц.

а если циклов 256, то 768 тактов....

0.2%

А действительно, зачем вообще что-либо делать?
Ведь можно продолжать смотреть диафильмы на проекторе с ручным приводом,

Код генерируемый GCC 15 инструкций, Ваш 13 - выигрыш по размеру примерно 20%.
Цикл генерируемый GCC выполняется за 23 такта, Ваш за 20, выигрыш 15%.

Конечно компилятор сработал не идеально, но по диафильмы - это уже
литературное преувеличение.

Как часто Вам надо очищать буфер в этой программе?

Анатолий.

Сообщение отредактировал aesok - Aug 17 2008, 23:40

[zltigo]

Как часто Вам надо очищать буфер в этой программе?

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