Перенос кода из под ИАРа на 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

[alx2]

Код

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

как показали эксперименты, как только в switch появляется второй case, в ассемблерном коде появляется вычисление незначащего старшего байта. Склоняюсь к выводу о недостатке оптимизатора в данном случае.

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

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

Во-вторых, я подозреваю, что вероятность выхода результата неких вычислений за границы диапазона (-128...127) намного выше чем диапазона (-32768...32767). Поэтому кодеру очень часто пришлось бы писать явное приведение к типу int, например писать (0 + a + b) / 2 вместо (a + b) / 2. Лично мне это бы не понравилось, т.к. во-первых, больше текста - больше вероятность ошибиться, а во-вторых, ухудшается читаемость кода. Почему тип приводится к int, а не к long или long long - я думаю, это компромисс между удобством и эффективностью. Случаи, когда диапазон значений int для вычислений недостаточен - достаточно редки чтобы явное приведение к long (long) не доставляло больших неудобств.

Наконец, что результат "в конце концов будет разрушен, будучи "обрезанным" и "запиханным" в signed char" - просто неверно, об этом aesok уже сказал.

Код

      x = (LCD_WIDTH + x - lcdGetStringWidth(text)) / 2;

Код

      x = (LCD_WIDTH + x - lcdGetStringWidth(text));
      x /= 2;

Первое и последнее выражения абсолютно эквивалентны по результату!

Не эквивалентны. В первом случае преобразование к типу char производится перед делением, во втором - после. Например при LCD_WIDTH=96, x=32 и lcdGetStringWidth(text)=0 результат этих выражений будет разным.

Сообщение отредактировал alx2 - Nov 29 2008, 11:53

[sonycman]

Поэтому кодеру очень часто пришлось бы писать явное приведение к типу int, например писать (0 + a + / 2 вместо (a + / 2. Лично мне это бы не понравилось, т.к. во-первых, больше текста - больше вероятность ошибиться, а во-вторых, ухудшается читаемость кода.

Зачем часто писать явное приведение к int? Разумнее сразу иметь хотя-бы одну переменную размерности int, если обработка данных типа char приводит к образованию переполнения
В моём случае (применительно к моему проекту) ситуация совсем обратная. Мне частенько приходится делать явное приведение к char
Почему? Потому что я резонно предполагал более эффективную работу восьмибитного ядра именно с "родным" типом данных - с char. Поэтому старался иметь максимальное количество переменных такого типа.

Не эквивалентны. В первом случае преобразование к типу char производится перед делением, во втором - после. Например при LCD_WIDTH=96, x=32 и lcdGetStringWidth(text)=0 результат этих выражений будет разным.

Ты говоришь про общий случай. Я - про строку кода конкретной функции lcdPrintText, в которой делимое всегда лежит в пределах 0 <= d < 96.
Поэтому эти выражения совершенно эквивалентны.
Ты можешь возразить - а откуда это может знать компилятор? Я соглашусь - не может он этого знать, он просто "железяка", которой внушили, что она много знает, и которой время от времени приходится "выпрямлять руки".

Но продолжим о "выражениях".
Благодаря стандарту, первое выражение имеет в два с половиной раза больший объём кода.
А если в программе таких выражений десятки? Тогда мы получаем в коде сотни байт ненужного мусора, что для маленьких кристаллов является актуальной проблемой.

Что мы делаем? Мы делаем явное приведение типов/разбиваем выражения на несколько частей и т.д. и т.п., что, как ты верно заметил,

лично мне это бы не понравилось, т.к. во-первых, больше текста - больше вероятность ошибиться, а во-вторых, ухудшается читаемость кода

в чём я полностью с тобой согласен!

Так что это палка о двух концах.

Да бог с этими стандартами.
Я попробую компилировать проект сразу в двух компиляторах - IAR и GCC. Хочу сравнить и отписаться об их "узких местах", так как меня это заинтересовало.
Может, ещё кому-то это будет интересно...

ЗЫ: вся эта возня с битами снова навела меня на мысль "пощупать" 16-ти битные MSP430. Как-то годик назад я взглянул мельком на несколько мануалов, но показалось, что они послабее периферией универсальных "мег"...

[aesok]

Я попробую компилировать проект сразу в двух компиляторах - IAR и GCC. Хочу сравнить и отписаться об их "узких местах", так как меня это заинтересовало.
Может, ещё кому-то это будет интересно...

Мне это будет интересно. Еще интереснее если Вы вооружитесь стандартом на
язык С и выступите в качестве третьего компилятора. Еще, GCC в первую очередь
компилятор стандартного языка С, во вторую компилятор для нескольких
популярных архитектур x86, ARM, 68k и уже в третью - четвертую компилятор для
AVR. Для AVR добавлено много оптимизаций, но всегда есть куда
совершенствоваться. Да но это не значит что на каждое Ваше хочу ктото кудато побежит
чегото делать, какие-то вещи невозможно сделать, какие-то очень трудно, на кикие-то
просто нет времени, а какаето просто не интересно делать. Не забывайте, что Вам никто
ничего не обязан.

Любая конструктивная и обоснованная критика принимается. Не конструктивная,
типа "мне ПОФИГ, что стандарт требует приведения выражения к int, я знаю что
при моих входных параметрах выражение никогда не даст в результате больше 96,
и я ХОЧЮ чтобы компилятор это угадал и использовав при расчетах тип char"
меня не интересует.

К сожалению в мои таланты не входит просто и доходчиво учить и разъяснять
положения стандарта и занимаюсь я этим очень редко и неохотно.

Это ссылка на стандарт: www.open-std.org/JTC1/SC22/WG14/www/docs/n1124.pdf

С уважением,
Анатолий.

[sonycman]

Не забывайте, что Вам никто
ничего не обязан.

Я разве здесь хоть что-то от кого-то потребовал?
Просто привожу вещи, которые мне непонятны/кажутся глупыми/достойными восхищения и т.д. и т.п.
И премного благодарен всем, кто наставляет меня "на путь истинный"
И, вероятнее всего, не только меня.

мне ПОФИГ, что стандарт требует приведения выражения к int, я знаю что
при моих входных параметрах выражение никогда не даст в результате больше 96,
и я ХОЧЮ чтобы компилятор это угадал и использовав при расчетах тип char

Если вы не поняли, то весь смысл про char был в одном - применительно к AVR это неудобно и неэффективно. С моей точки зрения. Никому её не навязываю и тем более никого не убеждаю изменять стандарты
А вот доводить до ума оптимизацию, думаю, нужно. В частности, по обработке switch?