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

[sonycman]

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

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

[Rst7]

Во-вторых, я подозреваю, что вероятность выхода результата неких вычислений за границы диапазона (-128...127) намного выше чем диапазона (-32768...32767).

Да ну? Рассмотрим операцию сложения. Независимо от размера - char или int - половина возможных операндов (немного меньше, без 2n, где n - количество разрядов) приведет к переполнению. А значит - вероятность почти 50% и не зависит от размерности

[AHTOXA]

А значит - вероятность почти 50% и не зависит от размерности

Но ведь 50% от 0xFFFF - это гораздо больше, чем 50% от 0xFF!

[Rst7]

Но ведь 50% от 0xFFFF - это гораздо больше, чем 50% от 0xFF!

Плохо Вы знаете определение вероятности. Вероятность - это отношение количества интересующих состояний к общему количеству состояний. В рассматриваемом случае вероятность одинакова (мелочь не учитываем). А уж абсолютные количества состояний - это совсем другой вопрос. Если выбирается разрядность 8, значит кодер чтото знает о свойствах своих переменных.

А вообще, истоки этого дела (расширение до int) в системе команд PDP-11. Так же, как и описание восьмиричных констант на символ меньше шестнадцатиричных (ребята из DEC'а очень любили восьмиричную систему)

С другой стороны лично я выработал некий набор костылей, которые позволяют писать код, хорошо ложащийся как на AVR, так и на ARM (или на другой 32хбитный камень, да и 16тибитный тоже). В частности, это регулярное применение каста (UREG) и (REG), а сами эти типы определяют размер регистра (например, char для AVR, int для архитектур с более высокой разрядностью). Код, конечно, для неподготовленного человека содержит приличное количество странной писанины, но зато с весьма хорошим результатом после компиляции. Еще один финт - минимизация использования знаковых переменных, т.к. это часто приводит к лишним операциям типа расширения знака.

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

[sonycman]

С другой стороны лично я выработал некий набор костылей, которые позволяют писать код, хорошо ложащийся как на AVR, так и на ARM (или на другой 32хбитный камень, да и 16тибитный тоже). В частности, это регулярное применение каста (UREG) и (REG), а сами эти типы определяют размер регистра (например, char для AVR, int для архитектур с более высокой разрядностью). Код, конечно, для неподготовленного человека содержит приличное количество странной писанины, но зато с весьма хорошим результатом после компиляции. Еще один финт - минимизация использования знаковых переменных, т.к. это часто приводит к лишним операциям типа расширения знака.

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

Спасибо за советы
Вас, видимо, весьма интересует тема оптимального кода.
Наверное, осталась привычка со времён спектрума?
Мне кажется, сейчас не каждый заглядывает в "недра" бинарников, особенно программеры PC софта.
За отсутствием необходимости?

Раскопал ещё один "пережиток стандарта".
Имеем текст:

Код

typedef    unsigned char    byte;
byte percent;
byte    maxRPM;
byte    minRPM;

percent = (maxRPM - minRPM) / 2;

и результат:

Код

            percent = (maxRPM - minRPM) / 2;
     6c0:    80 85           ldd    r24, Z+8; 0x08
     6c2:    90 e0           ldi    r25, 0x00; 0
     6c4:    21 85           ldd    r18, Z+9; 0x09
     6c6:    82 1b           sub    r24, r18
     6c8:    91 09           sbc    r25, r1
     6ca:    62 e0           ldi    r22, 0x02; 2
     6cc:    70 e0           ldi    r23, 0x00; 0
     6ce:    ee d8           rcall    .-3620; 0xfffff8ac <__eeprom_end+0xff7ef884>

Здесь вроде нет знаковых переменных, и нет сложения. Почему не сработала оптимизация?
Разве есть смысл в "запихивании" отрицательного значения в unsigned char? (впрочем, в ИАРе аналогичная фиговина)

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

За короткое время знакомства с GCC понравилось: удобная реализация атомарности через макросы ATOMIC_BLOCK(), удобная обёртка для обработчиков прерываний вида ISR(vector_name){}.

Так это как раз не компилятор, это просто библиотечные макросы. Аналогичные макросы можно сделать для любого минимально вменяемого компилятора.

Но разве есть подобные макросы для IAR? Там ведь приходится пользоваться громоздкой конструкцией с pragma и примитивными __disable_interrupt() и __enable_interrupt()...

[Rst7]

Там ведь приходится пользоваться громоздкой конструкцией с pragma и примитивными __disable_interrupt() и __enable_interrupt()...

Дык гдето в соседней ветке (кажется, "За что я не люблю Си") ктото привел макрос критической секции из цикла for, а я дальше выложил его вариант для IAR'а, с учетом его встроенных intrinsinc'ов. Кстати, есть еще в IAR'е всякие полезности типа __monitor, __save_interrupt и __restore_interrupt. Так что все не так плохо

К сожалению ответ тоже, да.

Я так и думал. Очень жаль. На самом деле внесенный баг весьма серьезен.

Вынужден констатировать, что многие опенсорсные проекты в конце концов превращаются в "жрите что дают". Да еще и морально подпитываются говнопиаром класса "халява рулит"

За сим откланиваюсь. Было приятно освежить в памяти подзабытые вещи благодаря конструктивной беседе с Вами.

[sonycman]

Дык гдето в соседней ветке (кажется, "За что я не люблю Си") ктото привел макрос критической секции из цикла for, а я дальше выложил его вариант для IAR'а, с учетом его встроенных intrinsinc'ов. Кстати, есть еще в IAR'е всякие полезности типа __monitor, __save_interrupt и __restore_interrupt. Так что все не так плохо

1. Посмотрю обязательно.
2. __monitor я и юзал. Жаль, что он работает только ко всей функции...

В ИАРе очень удобно сделана работа с указателями на память программ и eeprom. Она совершенно не отличается от указателей на оперативку
Хотелось бы видеть такое когда-нибудь и в GCC.

[alx2]

В ИАРе очень удобно сделана работа с указателями на память программ и eeprom. Она совершенно не отличается от указателей на оперативку
Хотелось бы видеть такое когда-нибудь и в GCC.

Можно в двух словах, как это сделано в IAR? Предполагаю, что там сделаны "универсальные указатели", которые включают не только адрес, но и идентификатор адресного пространства (код/данные). Кстати, опять же, IMHO ничто не мешает определить какой-нибудь класс u_pointer, хранящий такой указатель, и все необходимые для него операции. И не надо ждать, когда авторы компилятора что-то там сделают...

[sonycman]

Можно в двух словах, как это сделано в IAR? Предполагаю, что там сделаны "универсальные указатели", которые включают не только адрес, но и идентификатор адресного пространства (код/данные). Кстати, опять же, IMHO ничто не мешает определить какой-нибудь класс u_pointer, хранящий такой указатель, и все необходимые для него операции. И не надо ждать, когда авторы компилятора что-то там сделают...

Я без понятия, как там это сделано. Но выглядит вот так:

Код

__no_init __eeprom byte    ds1820romcodes[4][10]    @ 0x0;
static     unsigned char    ds18rom[4][10];

void    ds18Init(void)
{
    for(byte    a=0;a<40;a++)
    {
        ds18rom[0][a]    =    ds1820romcodes[0][a];
    }
}

Также и с обращением на чтение памяти программ:

Код

lcdPrintText("CPU");

void  lcdPrintText(char const __flash __flash *text)
{
  while(*text) lcdPutChar(*text++);
}