Микроконтроллер - как перспектива примочкостроения

[Rst7]

ЗЗЫ хотя вот это уже на глаза попадалось

О да, там срачик таки случился, но больше по архитектурным вопросам. Но, повторюсь, в том проекте порт стека с AVR на ARM занял два дня.

[ivana]

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

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

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

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

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

[Rst7]

Или ждем ответа KMG и держим общественность в напряжении?

Господин KMG не возжелал публично проводить работу над ошибками прямо в этой теме, постучал в асю, я ему там все разъяснил, он по свободной минутке обещал тут на основе этих разборов полетов сделать небольшую памятку для начинающих, ибо вопросы как раз классических граблей, через которые все проходят.

Ну а пока он соберется, еще есть возможность поразмышлять и понасиловать гугль самостоятельно, ибо

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

конечно да, но это такой, мелкий огрех, есть куда более злой, приводящий к полной неработоспособности кода.

[ivana]

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

KRS
Feb 21 2008, 13:19
Цитата(Rst7 @ Feb 21 2008, 13:01) *
А если еще и signed char, то вообще мраки начинаются...

Да тоже самое что и unsigned char, просто сдвиг другой для unsigned используется пара LSL/LSR а для signed LSL/ASR.

Вообще что бы код хорошо работал и на ARM и на AVR, я все локальные переменные объявляю uint_fast8_t, и все операции с переменными которые в памяти делаю через временные локальные объявленные как uint_fast8_t. Тогда все нормально загрузка идет через LDRB, а промежуточные операции все 32 битные (на ARM)
Тут главное помнить что uint_fast8_t может быть больше 8 бит....
примерно так
Код
uint8_t var;
void f(uint_fast8_t arg)
{
  uint_fast8_t tmp;
  tmp = var;
  if ( tmp > arg) tmp = arg+5;
  else tmp*=2;
  var = tmp;
}

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

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

[ivana]

Не, ну понятно желание господина KMG сэкономить время и пожалеть топик Ператрона, но а остальным страждущим и жаждущим познаний тоже хочется!  Я тут растекаюсь мыслями по древу, например 

ЗЫ а и ладно - тогда пока не подсказывайте и не разжевывайте - будем насиловать гугль и остатки собственных мозгов самостоятельно!  Но потом обязательно надо сверить полученные заблуждения! 

[Rst7]

ЗЗЫ ну и совсем слова идиота - насколько верна догадка, что локальные переменные компилятором стараются быть засунуты в РОН а глобальные в ОЗУ?

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

Тогда для изменения глобальной переменной лучше в функции присвоить её значение локальной регистровой, сравнивать раз 200 без операций выгрузки-загрузки в ОЗУ и только потом записать в глобальную - в ОЗУ?

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

Да и слова "uint_fast8_t" наводят на мысль что это указание компилятору использовать для данных переменных "быстрые" 8-битные РОН....

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

Смысл в том, что процессоры с разрядностью больше m>n обычно неэффективно в регистрах выполняют операции разрядностью n. Требуется лишний код на приведение типов. Посему правильно иметь регистровые переменные той же разрядности, как и регистры. Например, для ARM'ов:
uint8 - 8 бит
uint_fast8 - 32 бита
uint16 - 16 бит
uint_fast16 - 32 бита
uint32 - 32 бита
uint_fast32 - 32 бита
uint64 - 64 бит
uint_fast64 - 64 бита

Понятное дело, что для размещения переменных в памяти оптимально использовать размер не больше нужного, т.е. uint8/uint16 и т.д. А вот в регистрах - uint_fastX.

Потом очень мрачно смотреть на код, писанный в стиле для 8мибитника со сплошными char в коде при компиляции его на, скажем, ARM-архитектуру.

Так что к месту использование таких типов улучшает портабельность исходников на другие архитектуры.

По нынешним временам это актуально даже для большого брата, ибо int в архитектуре x64 остался 32хбитным, а регистры - 64хбитные. Со всеми вытекающими. Так что на большом брате надо тоже использовать uintX_fast_t.

Аналогичный вопрос может возникать при переносе, скажем, с архитектуры MSP (16 бит) как на AVR (8 бит), так и на ARM (32). Обычное бездумное использование int везде где можно на 16тибитных архитектурах при переносе на AVR приведет к перерасходу регистров, а на ARM - может повлечь за собой нежелательные эффекты за счет того, что int там не 16, а 32 разряда.

Не, ну понятно желание господина KMG сэкономить время и пожалеть топик Ператрона, но а остальным страждущим и жаждущим познаний тоже хочется!

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

[ivana]

Ай, спасибо, айболит Rst7! Вынес 2 момента
1) я ещё не полный идиот
2) "не мешайте лыжам ехать" (С одного лыжника) не усложняйте жизнь компилятору собственной ленью и неинформированностью

ЗЫ а интересно тут стало  Даже интереснее, чем на порнофоруме! 

ЗЗЫ ещё некоторое время не подсказывайте по первому багу с Дилей_Каунт... Хочется донасиловать мозг 

[ivana]

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

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

[Rst7]

Мне не хочется ожидать такой подставы от компилятора, что он для облегчения себе жизни просто перепишет её в свободный регистр и начнет сравнивать играючи без обращения к ОЗУ, где она декрементируется по прерыванию честно...

Это не подстава. Это - нормальный результат нормальной оптимизации. В Си есть средство для указания компилятору, что какая-то переменная может измениться поперек всего и он об этом может не знать. Это модификатор volatile.

Т.е. правильно было написать

Код: [Выделить]

volatile unsigned char DelayCnt;
(ну а на самом деле еще и volatile uint8_t DelayCnt)

И все, теперь компилятор в курсе дела, что переменная может модифицироваться без его ведома. И он будет ее действительно считывать из ОЗУ и проверять на каждой итерации цикла. Без этого модификатора действительно будет жопа - вечный цикл. Более того, даже проверки регистров не будет, только на 0 в самом начале функции, если 0 - выход, а если не 0 - то вечный цикл с вызовом функции Wdog.

Вот, собственно, и все вопросы и ответы на них. Стандартные грабли начинающих - о них забывать нельзя.

[ivana]

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

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

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

[Rst7]

Когда писал на ассемблере, я был единственным творцом логики и ответственным за свои же ошибки.

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

С другой стороны, современная парадигма компиляторостроения говорит, что "надо оптимизировать". Пусть у нас будет такой себе середячок-программист, но в среднем код будет терпимый - компилятор берет на себя работу по оптимизации. Зато за цену одного профессионала-ассемблерщика можно купить десяток педалистов на Сях средней руки. Пусть они сделают такое себе говнецо, но они сделают его быстрее - а значит, быстрее пойдут продажи готового продукта. Ну вот собственно говоря и философия компиляторостроения пришла к менеджерским терминам. Time to market, все дела.

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

[ivana]

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

[Rst7]

В Си есть такой момент, или это уже за гранью его возможностей и придется делать ассемблерные вставки?

Лучше делать асм-вставки. Дело в том, что подглядывая в листинг, можно, понятное дело, добиться того-же, чего и в рукопашную на ассемблере, но кто даст гарантию, что ничего не сломается при смене компилятора? Не с платформы на платформу, а с версии на версию, я имею в виду.

И вообще, не надо бояться асм-вставок/модулей, но наличие такого рукопашного кода надо минимизировать.

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

[ivana]

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

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

[Rst7]

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

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

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

Да ну, мне не жалко. "Спрашивайте - отвечаем" (ЦЭ) Просто неохота, чтобы тут говном всяким вроде бы и годную по идее тему заваливали.

[KMG]

Грабли вылезут в компиляторе с высокой степенью оптимизации кода
Без объявления 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
Зато и в прерываниях он во всех обращениях к переменной будет работать через память, но
этого можно избежать используя временную регистровую переменную.

[ivana]

Зато и в прерываниях он во всех обращениях к переменной будет работать через память

Каша пока у меня в голове... Нет, все вышенаписанное даже понятно, дело не в том... Когда мы уходим от ассемблера к Си, то поднимаемся на следующий уровень абстракции - от РОН и ОЗУ до переменных: локальных и глобальных. А тут компилятор сам царит (если не указать ему напрямую). Писал бы на ассемблере - выделил бы под счетчик тайминга отдельный РОН - безо всяких глобальных переменных и чтения-записей ОЗУ, его бы и прерывание изменяло и процедура проверяла... Собственно, так я и делал. А дальше, после того как процедура "Подождать" выполнилась - можно использовать этот РОН по другому назначению. Вот и думаю, как уложить это с тем, что

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

- даже на таком банальном примере... А Функция "Обождать Х ms" имхо используется чаще, чем какая-либо другая! По моему, её давно пора бы в стандартные Сишиные библиотеки для любого камня вынести - если она ещё не вынесена. А если вынесена - то почему KMG пишет её сам?

[Rst7]

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

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

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

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

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

А Функция "Обождать Х ms" имхо используется чаще, чем какая-либо другая!

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

[Rst7]

А дальше, после того как процедура "Подождать" выполнилась - можно использовать этот РОН по другому назначению.

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

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

Но тут вылезет другая проблема. Допустим, мы неимоверными мозговыми усилиями утоптали все в самый маленький камень. Все, там нет места ни по памяти, ни по быстродействию. А завтра случилась дикая необходимость что-то добавить в функционале. И что? Жопа? Переделывать весь прибор? Хорошо, если есть камень шире, но с той же функциональностью и железом. А если нет? Опять тонны ручной работы по переделке?

[research]

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