100 байт не хватает Опции

[Огурцов]

В общем, называется "приплыли", допрограммировались - бутлодырь перестал вмещаться в размер бутсекции, т.е. в 2k. Последним делом добавлено нечто такое:

Код

void Bus_transmit_packet(uint8 aStatus)
{
    uint16 vCrc;

    Bus_transmit_byte(Slp_packet_end);
    Bus_transmit_byte(Slp_packet_end);
    Bus_transmit_byte(Slp_sysdev_program | Slp_response_mask);
//    vCrc = vxl_get_crc16(Vxl_crc_ccitt_initial_value, Slp_sysdev_program | Slp_response_mask);
    Bus_staff_n_transmit_byte(aStatus);
    vCrc = vxl_get_crc16(0x7976, aStatus);
    Bus_staff_n_transmit_byte(vCrc >> 8);
    Bus_staff_n_transmit_byte(vCrc & 0xFF);
    Bus_transmit_byte(Slp_packet_end);
}

Что занимает примерно 60 байт. Предварительное заполнение массива и передача массива хоть и напрашивалась явно, но почти ничего не изменила или даже хуже.
Однако, где бы наскрести еще сотню байт ? (таблица векторов еще не затронута, как и секции инициализации/финализации) Поделитесь, pls, примером оптимизации - сам я боюсь все порушить и грохнуть что-либо нужное.

M88, GCC(WinAVR-20060421), cкрипты линкера от WinAVR-20081205

Сообщение отредактировал Огурцов - Dec 25 2008, 20:26

[Rst7]

в С оверхед жуткий из-за приведения всего к 32бит.

Где?

Код

        RSEG CODE:CODE:NOROOT(1)
//    3 unsigned long mmm(unsigned int a, unsigned int b)
mmm:
//    4 {
//    5   return (unsigned long)a*b;
        CLR     R2
        MUL     R17, R19
        MOVW    R23:R22, R1:R0
        MUL     R16, R18
        MOVW    R21:R20, R1:R0
        MUL     R17, R18
        ADD     R21, R0
        ADC     R22, R1
        ADC     R23, R2
        MUL     R19, R16
        ADD     R21, R0
        ADC     R22, R1
        ADC     R23, R2
        MOVW    R17:R16, R21:R20
        MOVW    R19:R18, R23:R22
        RET
//    6 }

[singlskv]

Где?

IAR в таких случаях действительно оптимизирует,
gcc увы следует стандарту и умножает 32X32

Код

  6a:    0c d0           rcall    .+24     ; 0x84 <__mulsi3>
.................................
00000084 <__mulsi3>:
  84:    62 9f           mul    r22, r18
  86:    d0 01           movw    r26, r0
  88:    73 9f           mul    r23, r19
  8a:    f0 01           movw    r30, r0
  8c:    82 9f           mul    r24, r18
  8e:    e0 0d           add    r30, r0
  90:    f1 1d           adc    r31, r1
  92:    64 9f           mul    r22, r20
  94:    e0 0d           add    r30, r0
  96:    f1 1d           adc    r31, r1
  98:    92 9f           mul    r25, r18
  9a:    f0 0d           add    r31, r0
  9c:    83 9f           mul    r24, r19
  9e:    f0 0d           add    r31, r0
  a0:    74 9f           mul    r23, r20
  a2:    f0 0d           add    r31, r0
  a4:    65 9f           mul    r22, r21
  a6:    f0 0d           add    r31, r0
  a8:    99 27           eor    r25, r25
  aa:    72 9f           mul    r23, r18
  ac:    b0 0d           add    r27, r0
  ae:    e1 1d           adc    r30, r1
  b0:    f9 1f           adc    r31, r25
  b2:    63 9f           mul    r22, r19
  b4:    b0 0d           add    r27, r0
  b6:    e1 1d           adc    r30, r1
  b8:    f9 1f           adc    r31, r25
  ba:    bd 01           movw    r22, r26
  bc:    cf 01           movw    r24, r30
  be:    11 24           eor    r1, r1
  c0:    08 95           ret

[aesok]

gcc увы следует стандарту и умножает 32X32

Дело не в стандарте, просто в avr back-end нет инструкций для (s/u)16x(s/u)16=32-умножения. Я смотрел это, в принципе их несложно добавить.

При их наличии может немного возрастать размер кода, но время выполнения уменьшиться.

Анатолий.

А вообще, хотел ответить в духе "ну и пусть этот гнусь вместе со своими адептами подхода "жрите что дают" убъются апстену", ну будем считать, что сдержался

Жрите что дают, не нравиться готовте сами, не умеете платите деньги... Не сдержался.....


Анатолий.

Сообщение отредактировал aesok - Dec 30 2008, 13:31

[singlskv]

Дело не в стандарте, просто в avr back-end нет инструкций для (s/u)16x(s/u)16=32-умножения. Я смотрел это, в принципе их несложно добавить.

про стандарт я имел в виду что gcc делает строго по стандарту, те "обязан"
при таком обращении преобразовать к 32бит.

На самом деле, ИМХО, стоило бы просто добавить в libc набор функций(частично инлайн)"
16x8=32
16x16=32
24x8=32
32/8=32
32/16=16
24/8=24
24/16=16
итд.

[aesok]

про стандарт я имел в виду что gcc делает строго по стандарту, те "обязан"
при таком обращении преобразовать к 32бит.

В GCC имеется полный набор шаблонов инструкций для описания 32 битных
операций умножения 'mulsi3', `ssmulsi3', `usmulsi3', где 'si' означеает
single integer (или 32-бит) mode 's' и 'u' signed/unsigned. Также есть набор
шаблонов для 16x16=32 бит умножения `mulhisi3', `umulhisi3', `usmulhisi3',
где 'hi' half integer (16-бит) mode размерность операндов и 'si" mode размерность
результата.

Так как последние не реализованы для avr платформы, то компилятор всегда
использует 32-битное умножение для 16- и 32-битных операндов, если необходим
32-битный результат.

Добавить эти инструкции несложно, при этом добаляются функции __mulhisi3,
__ssmulhisi3 __sumulhisi3, Но может оказаться так что в результирующем коде
вместо 4 вызовов функции __mulsi3, будет по одному вызову __mulsi3,
__mulhisi3, __ssmulhisi3 __sumulhisi3 при этом размер кода возрастет. Но все
равно в большинстве случаях должен быть выигрыш и в размере кода тоже, не
только в скорости.

Анатолий.

Сообщение отредактировал aesok - Dec 30 2008, 14:36