Перенос кода из под ИАРа на 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 в промежуточных вычислениях, прописано в стандарте.

[Rst7]

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

Ссылку. Чтото я совсем потерялся.

[msalov]

Ссылку. Чтото я совсем потерялся.

ISO/IEC 9899:1999

5.1.2.3 пункт 10

EXAMPLE 2 In executing the fragment

Код

char c1, c2;
/* ...  */
c1 = c1 + c2;

the ‘‘integer promotions’’ require that the abstract machine promote the value of each variable to int size
and then add the two ints and truncate the sum. Provided the addition of two chars can be done without
overflow, or with overflow wrapping silently to produce the correct result, the actual execution need only
produce the same result, possibly omitting the promotions.

6.3.1.1 пункт 2

If an int can represent all values of the original type, the value is converted to an int;
otherwise, it is converted to an unsigned int. These are called the integer
promotions.48) All other types are unchanged by the integer promotions.

48) The integer promotions are applied only: as part of the usual arithmetic conversions, to certain
argument expressions, to the operands of the unary +, -, and ~ operators, and to both operands of the
shift operators, as specified by their respective subclauses.