Перенос кода из под ИАРа на WinAVR, возникают некоторые вопросы... Опции

[sonycman]

Сейчас пытаюсь подогнать ИАРовский проект на меге88 под ВинАВР 4.3.2.
Чувствую, помучаться придётся немало

Пока не могу разобраться, как красиво прочитать/записать 16-ти битный таймер, обеспечив атомарность операции.
Аналога иаровского __monitor не нашёл.
Существуют ли подобные макросы? Или надо писать самому?

[sonycman]

Привет, sonycman!
Можно тестовый пример с версией и опциями компилятора?

Привет
Сейчас у меня вот такие опции:
Компилятор:

Код

Building file: ../Sources/main.cpp
Invoking: AVR C++ Compiler
avr-g++ -I"F:\Electronics\Projects\GNU\FanController\Headers" -Wall -g2 -gdwarf-2 -Os -fpack-struct -fshort-enums -mcall-prologues -std=gnu++98 -funsigned-char -funsigned-bitfields -fno-exceptions -fno-threadsafe-statics -fno-inline-small-functions -ffunction-sections -mmcu=atmega88 -DF_CPU=10000000UL -MMD -MP -MF"Sources/main.d" -MT"Sources/main.d" -c -o"Sources/main.o" "../Sources/main.cpp"

и линкер:

Код

Building target: FanController.elf
Invoking: AVR C++ Linker
avr-g++ -Wl,-Map,FanController.map,--cref -Wl,-gc-sections --relax -mmcu=atmega88 -o"FanController.elf"  ./Sources/CFanRegulator.o ./Sources/CTimer.o ./Sources/DS18S20.o ./Sources/Interrupts.o ./Sources/LCD.o ./Sources/USART.o ./Sources/debug.o ./Sources/generic.o ./Sources/main.o ./Sources/pwm.o  
Finished building target: FanController.elf

С включением опции -Wl,-gc-sections неиспользуемая копия встраиваемой функции исчезла.
Всё заработало правильно!

Видимо, потому что простой сдвиг не умещается в три процессорные инструкции. При отличной от -Os оптимизации генерится именно сдвиг.

И зря. "x / 2" и "x >> 1" - не эквивалентные операции. Они дают гарантированно одинаковый результат только для положительного x. Но в этом случае (если x имеет тип unsigned) gcc и код генерит одинаковый (со сдвигом), и нет никакого смысла писать одно вместо другого. У sonycman же, судя по приведенному им примеру, левый операнд имеет знаковый тип.

Да. Операнд имеет тип signed char. Именно в этом, видимо, и вся проблема. Спасибо, теперь я понял

[alx2]

Сейчас у меня вот такие опции:

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

Да ну? Где Вы это вычитали? Сдвиг в Си для знаковых операндов всю жизнь был арифметический, с учетом знака.

Читаем первоисточник:

The result of E1 >> E2 is E1 right-shifted E2 bit positions. If E1 has
an unsigned type or if E1 has a signed type and a nonnegative value, the value of the
result is the integral part of the quotient of E1 / 2^E2. If E1 has a signed type and a
negative value, the resulting value is implementation-defined.

When integers are divided, the result of the / operator is the
algebraic quotient with any fractional part discarded. 87)
.....
87) This is often called ``truncation toward zero''.

Обрати внимание, что результат оператора / - не есть целая часть арифметического частного.
И в качестве упражнения тестовый пример:

Код

alx2% cat test.c
#include <stdio.h>
int main(void)
{
    int x = -5;
    return printf("%d, %d\n", x / 2, x >> 1);
}
alx2% gcc -O2 -o t test.c
alx2% ./t
-2, -3

А вот то, что гнусь не поставил команду ASR, а позвал деление - это непонятно.

Попробуй привести код со сдвигами, выполняющий деление значения типа int (уже находящегося в регистрах) на 2, который был бы не длиннее трех машинных инструкций (напоминаю, что sonycman просил оптимизировать по размеру кода).

Сообщение отредактировал alx2 - Nov 26 2008, 21:00

[Rst7]

-2, -3

Однако, сдвиг действительно арифметический. Более подробно посмотрю этот момент, когда попаду за комп, потому как с трубы лень искать. Возможно, я и не прав.

Попробуй привести код со сдвигами, выполняющий деление значения типа int (уже находящегося в регистрах) на 2, который был бы не длиннее трех машинных инструкций (напоминаю, что sonycman просил оптимизировать по размеру кода).

Если уж быть точным, там тип signed char у sonycman, так что inc rx, asr rx вполне бы прошло.

[sonycman]

Однако, сдвиг действительно арифметический. Более подробно посмотрю этот момент, когда попаду за комп, потому как с трубы лень искать. Возможно, я и не прав.
Если уж быть точным, там тип signed char у sonycman, так что inc rx, asr rx вполне бы прошло.

Да, там у меня char:

Код

#define    LCD_WIDTH 96
byte  lcdGetStringWidth(PGM_P text);

void  lcdPrintText(PGM_P text, byte flags, signed char x, signed char y)
  switch(flags & 0xe0)
  {
  case  TXT_CENTERED:
    if (x < 0)
    {
      x = (LCD_WIDTH + x - lcdGetStringWidth(text)) / 2;
    }
...

Но смысла в нём мало - всё равно всё тупо "растягивается" до 16-ти бит ... даже switch:

Код

{
  switch(flags & 0xe0)
     e3a:    70 e0           ldi    r23, 0x00; 0
     e3c:    60 7e           andi    r22, 0xE0; 224
     e3e:    70 70           andi    r23, 0x00; 0
     e40:    60 38           cpi    r22, 0x80; 128
     e42:    71 05           cpc    r23, r1
     e44:    21 f0           breq    .+8      ; 0xe4e <lcdPrintText(char const*, unsigned char, signed char, signed char)+0x26>
     e46:    60 3c           cpi    r22, 0xC0; 192
     e48:    71 05           cpc    r23, r1
     e4a:    11 f5           brne    .+68     ; 0xe90 <lcdPrintText(char const*, unsigned char, signed char, signed char)+0x68>
     e4c:    1d c0           rjmp    .+58     ; 0xe88 <lcdPrintText(char const*, unsigned char, signed char, signed char)+0x60>
     e4e:    c4 2f           mov    r28, r20
     e50:    dd 27           eor    r29, r29
     e52:    c7 fd           sbrc    r28, 7
     e54:    d0 95           com    r29
  {
  case  TXT_CENTERED:
    if (x < 0)
     e56:    47 ff           sbrs    r20, 7
     e58:    0c c0           rjmp    .+24     ; 0xe72 <lcdPrintText(char const*, unsigned char, signed char, signed char)+0x4a>
    {
      x = (LCD_WIDTH + x - lcdGetStringWidth(text)) / 2;
     e5a:    da df           rcall    .-76     ; 0xe10 <lcdGetStringWidth(char const*)>
     e5c:    c0 5a           subi    r28, 0xA0; 160
     e5e:    df 4f           sbci    r29, 0xFF; 255
     e60:    9e 01           movw    r18, r28
     e62:    28 1b           sub    r18, r24
     e64:    31 09           sbc    r19, r1
     e66:    c9 01           movw    r24, r18
     e68:    62 e0           ldi    r22, 0x02; 2
     e6a:    70 e0           ldi    r23, 0x00; 0
     e6c:    17 d5           rcall    .+2606   ; 0x189c <__divmodhi4>
     e6e:    16 2f           mov    r17, r22
     e70:    0f c0           rjmp    .+30     ; 0xe90 <lcdPrintText(char const*, unsigned char, signed char, signed char)+0x68>
    }

Одно хоть радует - при вызове функции есть хоть какая-то польза от восьмибитных параметров - их быстрее загружать
А дальше всё равно бессмысленное "растягивание" до int... и впустую потраченное время и место во флэш.

[Rst7]

А дальше всё равно бессмысленное "растягивание" до int... и впустую потраченное время и место во флэш.

Вот именно. switch - хоть и int по стандарту, но если у него аргумент прямо в скобках &0xE0, то никаким стандартом не прикрыть недоточенность компилятора.


Аналогично есть вопросы к выражению. Все операнды и результат 8 бит, а в середине выражение вычисляется через 16 бит. Чтото не так.

[msalov]

Аналогично есть вопросы к выражению. Все операнды и результат 8 бит, а в середине выражение вычисляется через 16 бит. Чтото не так.

Это называется Integer promotion - приведение char к int в промежуточных вычислениях, прописано в стандарте.

[sonycman]

Это называется Integer promotion - приведение char к int в промежуточных вычислениях, прописано в стандарте.

Но неужели слепое следование стандартам больших машин - это абсолютно правильно и на AVR?
Неужели в вышеприведённом примере столь необходимо было следовать такому стандарту?

А может существует какая-то опция, позволяющая отключать эту фичу?