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

[sonycman]

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

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

[sonycman]

2aesok
Если у меня в программе операнд имеет тип char, то это значит, что ни при каких условиях не будет достигнуто переполнение.
Следуя вашей логике, можно и операнды типа word обрабатывать, расширяя до double word...

[aesok]

2aesok
Если у меня в программе операнд имеет тип char, то это значит, что ни при каких условиях не будет достигнуто переполнение.

Я вам привел пример когда оба операнда имеют тип char, и происходит переполнение.

Следуя вашей логике, можно и операнды типа word обрабатывать, расширяя до double word...

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

Анатолий.

Только не надо спрашивать, как это - "в другом стиле", на форуме выложенно достаточно, чтобы оценить кривость моих рук

Компилятор тоже не может этого оценить. Но он стараеться генерировать правильный код в не зависимости от кривости рук програмиста, при этом код иногда получаеться более длинным.

Анатолий.

[sonycman]

Я вам привел пример когда оба операнда имеют тип char, и происходит переполнение.

Этот пример не имеет ничего общего с моим приложением.
Как не трудно было заметить из моего примера, константа LCD_WIDTH всегда складывается с отрицательным числом. Плюс операнды имеют значения, не допускающие переполнения.

Насчёт кривости рук - что вы скажете про то, откуда берутся странные предупреждения об обязательной инициализации и так инициализированных строковых массивов, расположенных в памяти программ?

[aesok]

Этот пример не имеет ничего общего с моим приложением.
Как не трудно было заметить из моего примера, константа LCD_WIDTH всегда складывается с отрицательным числом. Плюс операнды имеют значения, не допускающие переполнения.

Это Ваш пример?

Код

#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;
    }

(LCD_WIDTH + x - lcdGetStringWidth(text)) = 96 + [-128..-1] - [0..255] = [95..-287]

Это чисто попещаеться в signed char? В unsigned char?

Насчёт кривости рук - что вы скажете про то, откуда берутся странные предупреждения об обязательной инициализации и так инициализированных строковых массивов, расположенных в памяти программ?

Исходники GCC находяться здесь http://gcc.gnu.org/viewcvs/ Вы можете убрать мешающие Вам предупреждения сами.

Анатолий.

Сообщение отредактировал aesok - Nov 27 2008, 19:54

[sonycman]

Это Ваш пример?

Код

#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;
    }

(LCD_WIDTH + x - lcdGetStringWidth(text)) = 96 + [-128..-1] - [0..255] = [95..-287]

Это чисто попещаеться в signed char? В unsigned char?

Нет. Но такие величины никогда не будут получены, так как операнды имеют значения, не допускающие переполнения. Не надо выдёргивать из контекста.

Исходники GCC находяться здесь http://gcc.gnu.org/viewcvs/ Вы можете убрать мешающие Вам предупреждения сами.

Как? Я, у которого в программе переполнения на каждом шагу, должен исправлять глюки "умного" компилятора, который стараеться генерировать правильный код в не зависимости от кривости рук програмиста?


Что-то мне кажется, что мы ведём непродуктивный диалог.

После того, как было установлено, что приведение операндов к 16-ти битам делается для того, чтобы просто удовлетворять стандарту, вы хотите сказать, что это не так?
Что на самом деле этот шаг направлен на предотвращение переполнения?

Как ты получил такой код??? =8-( )
Вот такой тестовый пример:

Код

int do_something(void);

void fff(char flags)
{
    switch(flags & 0xe0)
    {
        case 0x80:
            do_something();
    }
}

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

Код

fff:
/* prologue: function */
/* frame size = 0 */
        andi r24,lo8(-32)
        cpi r24,lo8(-128)
        brne .L4
        rcall do_something
.L4:
        ret

при любой -O отличной от -O0. gcc-4.3.1.
Скажи, пожалуйста, версию своего компилятора, с какой оптимизацией компилировался код и как определено byte.

Добрался до компа. На всякий случай повторю повнятнее:
У меня WinAVR 20081118rc2 с компилятором GCC 4.3.2.
Оптимизация Os плюс ещё несколько "фишек".
Командная строка компилятора:

Код

avr-g++ -I"F:\Electronics\Projects\GNU\FanController\Headers" -Wall -g2 -gdwarf-2 -Os -fpack-struct -fshort-enums -mcall-prologues -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"

Скомпилировал твой пример, вот что получилось:

Код

void do_something(char b)
{
    volatile static char a = b;
}

void fff(char flags)
{
    switch(flags & 0xe0)
    {
        case 0x80:
            do_something(0);
        case 0xc0:
            do_something(1);
    }
}


int main( void )
{


    fff(128);
...

и листинг:

Код

void fff(char flags)
{
    switch(flags & 0xe0)
    15be:    90 e0           ldi    r25, 0x00; 0
    15c0:    80 7e           andi    r24, 0xE0; 224
    15c2:    90 70           andi    r25, 0x00; 0
    15c4:    80 38           cpi    r24, 0x80; 128
    15c6:    91 05           cpc    r25, r1
    15c8:    21 f0           breq    .+8      ; 0x15d2 <fff(char)+0x14>
    15ca:    80 3c           cpi    r24, 0xC0; 192
    15cc:    91 05           cpc    r25, r1
    15ce:    29 f4           brne    .+10     ; 0x15da <fff(char)+0x1c>
    15d0:    02 c0           rjmp    .+4      ; 0x15d6 <fff(char)+0x18>
    {
        case 0x80:
            do_something(0);
    15d2:    80 e0           ldi    r24, 0x00; 0
    15d4:    e9 df           rcall    .-46     ; 0x15a8 <do_something(char)>
        case 0xc0:
            do_something(1);
    15d6:    81 e0           ldi    r24, 0x01; 1
    15d8:    e7 df           rcall    .-50     ; 0x15a8 <do_something(char)>
    15da:    08 95           ret

[aesok]

Нет. Но такие величины никогда не будут получены, так как операнды имеют значения, не допускающие переполнения. Не надо выдёргивать из контекста.

Причем тут я? Я человек я мог бы Вас и понять. Я Вам показываю как думает тупая железка, тоесть компилятор. Где Вы ему сказали что " операнды имеют значения, не допускающие переполнения"?

Я Вам показывал вариант как это ему сказать:
x = (byte) (LCD_WIDTH + x - lcdGetStringWidth(text)) / 2;

И компилятор начал вычислять выражение как 8-битное.

Как? Я, у которого в программе переполнения на каждом шагу, должен исправлять глюки "умного" компилятора, который стараеться генерировать правильный код в не зависимости от кривости рук програмиста?

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

После того, как было установлено, что приведение операндов к 16-ти битам делается для того, чтобы просто удовлетворять стандарту, вы хотите сказать, что это не так?
Что на самом деле этот шаг направлен на предотвращение переполнения?

Я попытался на примере Вам показать почему так написан стандарт.

Добрался до компа. На всякий случай повторю повнятнее:

Пока не знаю.

Анатолий.

Сообщение отредактировал aesok - Nov 27 2008, 22:28

[sonycman]

Я попытался на примере Вам показать почему так написан стандарт.
Анатолий.

Хм... то есть, разработчики стандарта таким образом подстраховали все вычисления с операндами типа char?
Мне всё равно трудно понять рациональность этого хода.
Потому, что ошибка с переполнением может возникнуть с любым по размеру операндом: 8, 16, 32, 64 и так далее бит.
Почему для 8-ми бит сделали исключение?

(LCD_WIDTH + x - lcdGetStringWidth(text)) = 96 + [-128..-1] - [0..255] = [95..-287]

Зачем "правильно" считать результат на 16-ти битах, если в конце концов он будет разрушен, будучи "обрезанным" и "запиханным" в signed char?
Если программист не продумал все варианты - ошибка обязательно вылезет всё равно.

Да...
Но всё-же, спасибо за попытку всё объяснить. Извиняюсь за некоторое раздражение в моём тоне.
В любом случае, стандарты придумывают весьма умные дядьки, не чета таким, как я
Порой трудно бывает понять их мотивы. Воистину, пути их неисповедимы

[aesok]

Хм... то есть, разработчики стандарта таким образом подстраховали все вычисления с операндами типа char?
Мне всё равно трудно понять рациональность этого хода.
Потому, что ошибка с переполнением может возникнуть с любым по размеру операндом: 8, 16, 32, 64 и так далее бит.
Почему для 8-ми бит сделали исключение?

На самом деле исключение сделано для int. Это как бы тип по умолчанию,
разрядность int обычно равна разрядности регистров общего
назначения, что гарантирует максимальную производительность для этого типа.
Для AVR разрядность int больше разрядности регистра. Сделать int 8-битным
нельзя, в стандарте требуется - размерность указателя равна размерности int,
а 8-битный указатель это слишком мало.


Если быть совсем точным то avr-gcc имеет ключ:
-mint8 Use an 8-bit 'int' type

Его практическая ценность его мала, avr-libc не совместима с этим ключом, и
никогда не будет. Но если будете писать что нибудь маленькое, можете с ним
поиграться.

Зачем "правильно" считать результат на 16-ти битах, если в конце концов он будет разрушен, будучи "обрезанным" и "запиханным" в signed char?
Если программист не продумал все варианты - ошибка обязательно вылезет всё равно.

Потому что в вашем примере обрезание рузультата до char произойдеи уже после деления, а для того чтобы результат деления на 2 влез в char делимое может иметь значение до char * 2, и для его хранения нужен int.

Порой трудно бывает понять их мотивы. Воистину, пути их неисповедимы

На самом деле все очень просто, отладив несколько своих проектов Вы начнете думать как они...

Анатолий.

Сообщение отредактировал aesok - Nov 27 2008, 23:26