ARM7 сравнение компиляторов, провел небольшое исследование Опции

[KRS]

компиляторы -
IAR V5.40.2.51604/W32
RVCT4.0 [Build 650]
(Sourcery G++ Lite 2009q1-161) 4.3.3

Задача:
распаковка LZMA из внутренней Flash, только распаковка, данные никуда не отсылаются.
запакованный размер - 244625
распакованный - 605992
размер словаря 8 кб
данные - прошивка от блекфина.
оптимизация максимальная по скорости

Платформа:
ARM - LPC2138
частота 50 Mhz MAM включен

размер кода (только декодер)

Код

       IAR    RVCT  GNUC
ARM    3032   3284  3844
THUMB  2372   2514  2844

Время выполнения в ms (измерял с помощью таймера с прескалером 0)
код выполнялся из памяти

Код

       IAR    RVCT  GNUC
ARM    1754   1737  2212
THUMB  2720   2761  2494

код из флеша

Код

       IAR    RVCT  GNUC
ARM    1954   1950  2323
THUMB  2870   2942  2738

В тумбе IAR генерит более быстрый и компактный код по сравнению с RVCT.
В ARM из flash разница в скорости ~0.2% что несущественно, а вот код ~8% компактнее.

С GNUC - интересно в тумбе код большой, но более быстрый. Посмотрел по листингу - это связано с тем что GNUC в тумбе использует r8, r9 ( r10,r11 не использовал)

PS - общий проект в IAR, разными компиляторами компилировал только функцию декодера, а т.к. все EABI, то IARовсикй линкер без проблем жрал. Поэтому измерение времени для разных компилеров корректно - именно время распаковки.

Сообщение отредактировал KRS - Oct 27 2009, 16:15

[KRS]

На примере простого кода, работы с битовыми полями, я его уже давно как то выкладывал, для версий 4.42, 5.11 и RVCT (уже не помню какого)

Код

struct bf_s {
    unsigned f1:6;
    unsigned f2:2;
    unsigned f3:20;
    unsigned f4:4;
} bf;

void short_clear(void)
{
  bf.f2 = 0;
}

void short_set(void)
{
  bf.f2 = 3;
}

void short_const(void)
{
  bf.f2 = 1;
}

void short_var(unsigned val)
{
  bf.f2 = val;
}

void long_clear(void)
{
  bf.f3 = 0;
}

void long_set(void)
{
  bf.f3 = (1<<20)-1;
}

void long_const(void)
{
  bf.f3 = 1;
}

void long_var(unsigned val)
{
  bf.f3 = val;
}

void long_var_if(unsigned val,unsigned cond)
{
  if (cond) bf.f3 = val;
  else bf.f4=val;
}

unsigned a;
unsigned b;
unsigned c;
void var_if(unsigned val)
{
  if (val) a = c;
  else b = c;
  c = val;
}

Сейчас скомпилил последним иаром V5.40.2.51604/W32
Улучшений серьезных нет
BFI и условное выполнение до сих пор IAR делать не умеет!
Для примера листинг одной функции

Код

RVCT -O3 -Otime --cpu Cortex-M3
long_var_if PROC
        LDR      r3,|L1.176|
        CMP      r1,#0
        LDR      r2,[r3,#0]
        ITE      EQ
        BFIEQ    r2,r0,#28,#4
        BFINE    r2,r0,#8,#20
        STR      r2,[r3,#0] ; bf
        BX       lr
        ENDP


IAR --cpu Cortex-M3 -Ohs
long_var_if:
            LDR.N    R2,??DataTable13 ;; bf
            LDR      R3,[R2, #+0]
            CBZ      R1,??long_var_if_0
            LDR.N    R1,??DataTable14 ;; 0xf00000ff
            ANDS     R1,R1,R3
            LDR.N    R3,??DataTable15 ;; 0xfffff00
            AND      R0,R3,R0, LSL #+8
            ORRS     R0,R0,R1
            B.N      ??long_var_if_1
??long_var_if_0:
            LSLS     R1,R3,#+4
            LSRS     R1,R1,#+4
            ORR      R0,R1,R0, LSL #+28
??long_var_if_1:
            STR      R0,[R2, #+0]

            BX       LR

[KRS]

На примере простого кода, работы с битовыми полями, я его уже давно как то выкладывал, для версий 4.42, 5.11 и RVCT (уже не помню какого)

Еще раз посомтрел листинги, и заодно GNUC попробовал.
GNUC - BFI использует! А вот условное выполнение нет .
А вот новый IAR оказывается умеет иногда использовать условное выполнение и почему не всегда - загадка, вот листинги последней функции

Код

GNUC gcc version 4.3.3 (Sourcery G++ Lite 2009q1-161)  -O3
var_if:
    @ args = 0, pretend = 0, frame = 0
    @ frame_needed = 0, uses_anonymous_args = 0
    @ link register save eliminated.
    push    {r4}
    mov    r4, r0
    cbnz    r0, .L29
    movw    r1, #:lower16:c
    movt    r1, #:upper16:c
    movw    r2, #:lower16:b
    ldr    r3, [r1, #0]
    movt    r2, #:upper16:b
    str    r3, [r2, #0]
.L27:
    str    r4, [r1, #0]
    pop    {r4}
    bx    lr
.L29:
    movw    r1, #:lower16:c
    movt    r1, #:upper16:c
    movw    r2, #:lower16:a
    ldr    r3, [r1, #0]
    movt    r2, #:upper16:a
    str    r3, [r2, #0]
    b    .L27

IAR

var_if:
            LDR.N    R1,??var_if_0   ;; a
            LDR      R2,[R1, #+8]
            CMP      R0,#+0
            ITE      NE
            STRNE    R2,[R1, #+0]
            STREQ    R2,[R1, #+4]
            STR      R0,[R1, #+8]

            BX       LR              ;; return


RVCT
var_if PROC
        LDR      r2,|L1.176|
        CMP      r0,#0
        LDR      r1,[r2,#0xc]
        ITE      EQ
        STREQ    r1,[r2,#8] ; b
        STRNE    r1,[r2,#4] ; a
        STR      r0,[r2,#0xc] ; c
        BX       lr
        ENDP

как видно еще GNUC по другому подходит к загрузке адреса в регистр!
Но IMHO это неоптимально, вместо одной 16 битной инструкции и 32 бит данных используется две 32 битных команды.

[AHTOXA]

как видно еще GNUC по другому подходит к загрузке адреса в регистр!
Но IMHO это неоптимально, вместо одной 16 битной инструкции и 32 бит данных используется две 32 битных команды.

Это для скорости, так наверное конвейер не слетает При -Os gcc грузит адрес одной инструкцией.

[klen]

Генерит GCC условные команды IT
я взял асм своего проека где Stm32 UsbLib использую - там вот обнаружился такой кусок к примеру

void ClearDTOG_RX(uint8_t bEpNum)
{
800160e: b2c0 uxtb r0, r0
_ClearDTOG_RX(bEpNum);
8001610: f853 2020 ldr.w r2, [r3, r0, lsl #2]
8001614: f412 4f80 tst.w r2, #16384 ; 0x4000
8001618: bf1f itttt ne
800161a: f853 1020 ldrne.w r1, [r3, r0, lsl #2]
800161e: f648 728f movwne r2, #36751 ; 0x8f8f
8001622: 400a andne r2, r1
8001624: f442 4280 orrne.w r2, r2, #16384 ; 0x4000
8001628: bf18 it ne
800162a: f843 2020 strne.w r2, [r3, r0, lsl #2]
}
800162e: 4770 bx lr
8001630: 40005c00 .word 0x40005c00

далее я взял примерно такойже кусок кода как выше указывался:

Код

struct bf_s {
    unsigned f1:20;
    char f2:8;
    char f3:8;
    unsigned f4:20;
} bf;

void long_var_if(char val,char cond)
{
  if (cond)
   {
      bf.f3 = val;
      bf.f1 = val;
      bf.f2 = val;
   }
  else
      bf.f4=val;
}

char var_if(char a ,  char b  )
{
  char x = a;
  if (a)
    {
      x = b;
    }  
  return x;  
}

arm-kgp-elf-gcc -mthumb -march=armv7-m -mcpu=cortex-m3 -S -O3 test2.c

результат:

Код

    .syntax unified
    .thumb
    .file    "test2.c"
    .text
    .align    2
    .global    long_var_if
    .thumb
    .thumb_func
    .type    long_var_if, %function
long_var_if:
    @ args = 0, pretend = 0, frame = 0
    @ frame_needed = 0, uses_anonymous_args = 0
    @ link register save eliminated.
    tst    r1, #255
    itete    ne
    ldrne    r3, .L4
    ldreq    r3, .L4
    ldrne    r2, [r3, #0]
    ldreq    r2, [r3, #4]
    uxtb    r0, r0
    itett    ne
    bfine    r2, r0, #0, #20
    bfieq    r2, r0, #8, #20
    strne    r2, [r3, #0]
    strbne    r0, [r3, #4]
    ite    ne
    strbne    r0, [r3, #3]
    streq    r2, [r3, #4]
    bx    lr
.L5:
    .align    2
.L4:
    .word    bf
    .size    long_var_if, .-long_var_if
    .align    2
    .global    var_if
    .thumb
    .thumb_func
    .type    var_if, %function
var_if:
    @ args = 0, pretend = 0, frame = 0
    @ frame_needed = 0, uses_anonymous_args = 0
    @ link register save eliminated.
    uxtb    r1, r1
    uxtb    r0, r0
    cmp    r0, #0
    ite    ne
    movne    r0, r1
    moveq    r0, #0
    bx    lr
    .size    var_if, .-var_if
    .comm    bf,8,4
    .ident    "GCC: (GNU) 4.5.0 20091029 (experimental)"

из сего видно что GCC прекрасно генерит BFI и IT команды. Другое дело что не ВСЕГДА КОГДА НАМ ЭТО ОЧЕВИДНО! полазив по исходникам компилера я увидел что допустим IT или переходы, например BNE являются для него алтернативами в зависимоти от ситуации принимается решение генерить то или иное. Если учесть что IT способно обойти и загрузить конвеер Cortex'а не более чем на 4 инструкции то становится понятным почему короткий if компиллер генерит через IT а более длинный с его точки зрения (n>4) генерится переход. Есть желание думать что скорость нада проверять а не наличие тех или иных команд.

собсно примерно так.

[KRS]

из сего видно что GCC прекрасно генерит BFI и IT команды. Другое дело что не ВСЕГДА КОГДА НАМ ЭТО ОЧЕВИДНО! полазив по исходникам компилера я увидел что допустим IT или переходы, например BNE ...

да это все известно и из описания архитектуры, для этого лезть в исходники компилера не надо!
в моем варианте функции var_if - GNUC явно полез оптимизировать нетуда! в итоге функция неимоверно больше по размеру, использует стек! и явно медленне работает!
Про BFI - я сразу говорил что гнусь это умеет! Вот что что а а все подобные иснтуркции гнусь всегда задействует. у IAR с BFI проблема пока.

По поводу Вашей функции var_if - вообще смешно!!!

RVCT - ее скомпилировал так

Код

var_if PROC
        CMP      r0,#0
        IT       NE
        MOVNE    r0,r1
        BX       lr
        ENDP

по поводу UTX - конечно можно спорить, но это явно лишнее, раз указано что на входе char, дополнительно чистить его не надо, это должна делать вызывающая сторона! арифмитических опреаций с переменными здесь не проводится так что переполнения в старшие биты быть не может!

листинг первой функции, выкладывать не буду, но он тоже оптимальнее и код красивее.

[dch]

обычно компиляторы несравниваются по наличию ошибок, по тому какой суппорт удается получить и как быстро компилятор переползает на новую архитектуру, пока не начинаются подмены ресурсов на публичных сайтах public domain или близкие к нему GNU ресурсы обычно достаточно надежны, впрочем наверное начинать писать свой кроскомпилятор уже наверное можно, судя
по количеству несанкционированного доступа к инет реурсам.