Цитата:

Ну вот и я к тому же Зато как оптимально может выглядеть код! Правда мне при этом всегда страшно - этот кусок производит впечатление кого-то очень умного но ненадежного Потихоньку собираю стереотипы и традиции, что народ предпочитает...

ЗЫ Про первые грабли надумал только, что не всякий интеджер влезет в ансигнед чар... Или ждем ответа KMG и держим общественность в напряжении?

ЗЗЫ ну и совсем слова идиота - насколько верна догадка, что локальные переменные компилятором стараются быть засунуты в РОН а глобальные в ОЗУ? Тогда для изменения глобальной переменной лучше в функции присвоить её значение локальной регистровой, сравнивать раз 200 без операций выгрузки-загрузки в ОЗУ и только потом записать в глобальную - в ОЗУ?  Да и слова "uint_fast8_t" наводят на мысль что это указание компилятору использовать для данных переменных "быстрые" 8-битные РОН....

ЗЗЫ вы уж меня простите, мне просто надоело умничать на порно-форуме, теперь пытаюсь влезть в эту предметную область 

Интерееееесная штуковина...  Хотел найти в гугле что значит "uint_fast8_t" - наткнулся вот на что  (И везде эта аббревиатура Rst7 почему-то появляется!  )

Цитата:


Половину не понял, но мне кажется, что общая мысль прослеживается

ЗЗЫ вернется Ператрон, "а голова в тумбочке"... 

Цитата:


Именно так. Только глобальные - они всегда в ОЗУ, а локальные - по возможности в РОН, а если не лезет, то в ОЗУ.

Цитата:


Безусловно. Конечно, современные компиляторы стараются избавляться от лишних обращений к памяти, но все равно, человек это лучше - ему виднее в комплексе. Правда, попытки такой оптимизации именно компиляторами ведут к первым граблям. Это типа подсказка

Цитата:


Ну для конкретной платформы можно написать и unsigned char, как собственно и сделано. А вот для портабельности кода без потери производительности для регистровых переменных следует указывать именно типы uint_fastX_t. Приведу развернутое объяснение этого, которое я написал для господина KMG в асе
Цитата:


Цитата:


Вот и я ему то же предлагал. А этот топик жалеть не надо после ссылок на говносайты. Пусть тут будет "школа молодого бойца" вменяемая.

Цитата:

У нас там одна единственная переменная, объявленная как глобальная - значит в ОЗУ. В функции Дилей камень не спит (как опять бы сделал я, простите за наглость ), а мучает эту переменную сравнениями множество раз... Мне не хочется ожидать такой подставы от компилятора, что он для облегчения себе жизни просто перепишет её в свободный регистр и начнет сравнивать играючи без обращения к ОЗУ, где она декрементируется по прерыванию честно... 

Лалала!... Нет слов - одни эмоции! Когда писал на ассемблере, я был единственным творцом логики и ответственным за свои же ошибки. Выделял регистры САМ и знал что в каком лежит И КАКИЕ МОЖНО КОРЕЖИТЬ А КАКИЕ НЕЛЬЗЯ! А на Си получается творим Хекс на пару - в соавторстве с компилятором, да ещё с его разными опциями, а отвечаю за общие ошибки я один!  И чтобы не было подстав от коллеги, придется изучать его характер

ЗЫ спасибо за очевидные для тех кто в теме и такие интересные моменты для меня! 

ЗЗЫ надеюсь, не последний раз 

Хорошее видение ситуации с высоты имеющейся информации
Ну. раз пошла такая пьянка - то ещё момент - в моей единственной  (не считая моргания светодиодами) написанной задаче на ассемблере, мне требовалось проводить измерения малых времен, при данной частоте камня надо было, чтобы цикл вне зависимости от того, по какой ветке пойдет внутри выполнение кода всегда выполнялся определенное количество тактов, которые я считал по каждой команде ассемблера с точностью до одного (потому что их было мало на цикл и нужна была такая точность). В Си есть такой момент, или это уже за гранью его возможностей и придется делать ассемблерные вставки?

Да, надо было в аську уходить.... Но для этого её надо скачать ещё и поставить, зарегиться... 
Метод "сначала топором а потом доработать напильником" имхо тоже лежит на поверхности и просится в жизнь... И вставки - я укажу номер регистра напрямую, а значит надо знать какой РОН компилятор для чего заюзал? А если он решит передумать после незначительной смены кода? Сорри за тупые вопросы - просто никак "не сходится" у меня структура МК и буквы на Си! 
Просто никак не могу примириться и довериться компилятору - в плане того, как он будет делать асм и самое прикольное - какие регистры для чего и как использовать... Просто нет опыта "езды на лошади" со своим характером, только пешком сам походил

ЗЫ Rst7, я тебе наверное уже денег должен Просто с одной стороны мне классно, что получаю важную информацию, а с другой неудобно немного отнимать твое ваше время...

Грабли вылезут в компиляторе с высокой степенью оптимизации кода
Без объявления DelayCnt volatile

unsigned char      DelayCnt;
...
//  114 Delay(int ValmS)
Delay:
//  115 {
//  116      DelayCnt = ValmS;
        STS     DelayCnt, R16
//  117      while (DelayCnt != 0)
        TST     R16
        BREQ    ??Delay_0
//  118      {
//  119            Wdog();
??Delay_1:
        RCALL   Wdog
        RJMP    ??Delay_1
//  120      }
//  121 }
??Delay_0:
        RET
В заоптимизированном коде видно что попадаем в цикл из которого нет выхода
После исправления

volatile      unsigned char      DelayCnt;
...
//  114 Delay(int ValmS)
Delay:
//  115 {
//  116      DelayCnt = ValmS;
        STS     DelayCnt, R16
        RJMP    ??Delay_0
//  117      while (DelayCnt != 0)
//  118      {
//  119            Wdog();
??Delay_1:
        RCALL   Wdog
//  120      }
??Delay_0:
        LDS     R16, DelayCnt
        TST     R16
        BRNE    ??Delay_1
//  121 }
        RET
Зато и в прерываниях он во всех обращениях к переменной будет работать через память, но
этого можно избежать используя временную регистровую переменную.

Цитата:


Никаких расхождений теории и практики. Проблема немного более тонка. Это в рассматриваемом примере регистров валом. А обычно они все заняты - кодом, который выполняется. Чем интенсивнее код использует регистры - тем он оптимальнее, и по быстродействию, и по размеру.

Кроме того, в принципе, для AVR есть возможность указать компилятору оторвать несколько регистров для рукопашного использования. Иногда, в крайних случаях, этим можно пользоваться - например, для оптимизации процедур прерывания, когда каждый такт на счету и, например, убирание пролога и эпилога функции прерывания (которые заняты сохранением/восстановлением регистров в/из стека) дает приличный выигрыш по производительности.

Однако, тут стоит смотреть на проблему в комплексе. Если вычисления в обычных функциях достаточно тяжелы и отнятие регистров приводит к тому, что в функциях все локальные переменные в регистры не помещаются - обычно происходит резкое падение производительности основного кода.

Так что надо выбирать - "или шашечки, или ехать".

Цитата:


Это она в таком очень простом примере используется так вот в наглую. В довольно обширных системах обычно таких процедур ожидания нет - ибо в это время проц просто простаивает. А обычно надо еще что-то делать. Но тут на помощь приходят всякие операционные системы реального времени с их потоками, сообщениями и прочим. Не обязательно общедоступные (например, FreeRTOS), часто и просто некие самописные вариации на тему RTOS.

Кстати, как у ARM при работе с оперативной памятью дело обстоит? 1 такт, или больше?  Всеми нелюбимый (один из), например, первые 8к ОЗУ за 1 такт отрабатывает. переменных вмещается прилично.