При достаточно хорошем владенни С вполне можно писать код настолько же плотный как и на ассемблере.
1.inline - убирает самую расходную часть кода - call и пролог/эпилог.
2.nacked/task - дает возможность написать пролог/эпилог самому.
3.Сишный код компилируеться в ассемблер и правиться руками.


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

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

Да, это и есть Enter с нулевой вложенностью стековых кадров. Чтобы понять, что такое вложенные стековые кадры, вспомните Паскаль - там внутри одной процедуры можно описать другую процедуру, из которой будут видны локальные переменные объемлющей процедуры, но внутренняя будет недоступна для основного кода модуля. Так вот, при входе во внутреннюю процедуру вызывается Enter с параметром вложенности 1, копируя в текущий стековый кадр адрес стековых кадров всех объемлющих процедур (в данном случае одной, но можно до 31).
А вложенность уровня 0 - это просто 2 инструкции
sub SP,const
mov BP,SP
То, что эту последовательность двух команд обозначили одним новым словом, почти не даёт преимуществ (по крайней мере никакого торжества Фуджиков по этому поводу не намечается).

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


Ключевое слово - "ручками". Они у всех разные. Если вы изучаете асм по Сишным листингам и учитесь у составителей компилятора - то и ручки будут соответствующими. А если осмыслить всю задачу изначально без ЯВУ-шных предвзятостей, то ручки будут творить чудеса и простор вашей фантазии поразит вас самого. Сама психология следования традициям общих подходов, применяемых в компиляции с ЯВУ, ущербна.



Есть и исключение - копирование в AVR регистровой пары в другую регистровую пару - 1 такт.

Излишнее количество адресных пространств не даёт никакого проигрыша в скорости обращения к ним. К расширенным портам ввода-вывода обращение эквивалентно обращению к памяти (так, как вам и нравится).


За 1 такт - выводом единичного бита в нужный пин одной инструкцией OUT PINB,reg



Очень правильная последняя фраза. В ней сокрыто основное преимущество АСМа, роль которого никогда не перестанет быть важной.



В рамках своей идеологии компиляторы генерят код насколько могут хорошо. Но рядовой (или не очень) программист на ассемблере просто сделает шаг в сторону от натоптанной компиляторами дорожки и получит выигрыш в разы. Жаль, что многие обсуждающие эту тему (например, в этой ветке), не понимают этого, зашоренные стандартными подходами. Для программиста на АСМе нет прокрустова ложа (то есть, грамматики ЯВУ), стоящего между семантикой исходной задачи и возможностями железа. Нет этого посредника, обязательность присутсвия которого увеличивает накладные расходы (в смысле оптимальности получаемого кода). Единственное оправдание ЯВУ - это время разработки софта и универсальность обучения кодеров. То есть, жертвуя оптимальностью программы, мы удешевляем её разработку. Использование ЯВУ - это баланс между техническими и экономическими интересами, а вовсе не "светлое будущее" программирования.



Экий самоуверенный разработчик с претензиями Икара.



Вот-вот, видимо о таком и речь.

Вот и я поддерживаю данное высказывание на 100%. Правда по другой причине. Вылизывание Сишного кода (примеров на форуме очень много) всегда опирается на особенности компилятора. Это фактически уже тот же ассемблер с вывертом. Поясню. Когда очень долго пишешь на ASMе, то не пишешь операторами, а в голове у тебя давно сидят целые куски когда-то вылизанные. И пишешь то легко и спокойно. Я на спор написал прогу с ЖКИ, редактором, I2C, ADC, DAC, Modbus на ASMе. Быстрее программиста на Си. И отладил быстрее. И прога значительно красивее работала (в смысле редактора). Её и за основу взяли.
Но .... Си нужен для хорошей портируемости. Возможности развития програмного продукта. Его сопровождения. И выверты в данном случае приведут к необходимости переписывания проги при каждой смене кристала или компилятора. Так нафига тогда Си вааще...
Надо выбирать платформу с запасом, писать максимально независимо, укрупнять где возможно, предусматривать возможность развития.

Конечно это чисто мой взгляд на вещи. Я тут обжёгся с одним изделием. Начинал ещё на 51+мелочёвка. Потом перенёс на 4414+1200, потом на mega8. А теперь смотрю с отвращением, а оно живёт! Придётся на at91sam7s переносить. Фактически заново разрабатывать! Я его уже ненавижу!

Инверсия пина в AVR, если Вы не знаете, выполняется, например, так:

Ни разу не один такт!

Кстати, OUT PINB,reg - это попытка прописать значение в регистр, предназначенный для чтения с порта. Кто-то у Вас туговато вышло - в одном утверждении две грубых ошибки. Боюсь, что и Ваши рассуждения про убогость, зашоренность компиляторов (и их разработчиков) и свободу и невыразимый полет мыслей при невероятной эффективности результата с использованием ассемблера по соответствию действительности весьма коррелируют с вышеотквоченным.

В новых кристалах - например в М88 out в PINx действительно приводит к инверсии установленных в 1 битов. Так что вы зря напали на человека, да еще и в таких выражениях...

Не согласен. inline - стандартная фича переносимая на все 100%. Тот же макрос, но с проверкой параметров. nacked/task не настолько экономен и переносим, но в хорошо вылизанном коде его стоит использовать. Вопрос собсно состоит в том, насколько стоит увлекаться ручной оптимизацией. Если проект разовый наверное нет, если с долгим жизненным циклом - доводить в каждой новой итерации.

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

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

К вопросу грамотного использования макроязыка
ассемблера AVR для структурирования ассемблерных программ

См: http://www.forth.org.ru/~IN4/

Вообще не пойму вокруг чего весь базар - кодить на ассемблере, особенно на авровском - одно удовольствие, на Ц - тоже, но совсем другое.

Или сейчас в почёте у эмбеддеров знание не более чем одного языка ?

Во-первых, надо было уточнять, т.е. прямо сказать, что это, дескать, вчера фича появилась в последнем кристалле, на который и дока-то еще Preliminary. AVR выпускается почти 10 лет и все выпущенные до сих пор кристаллы ничего подобного не имели, и мое высказывание имеет к ним прямое отношение. Кстати, это в значительной мере характеризует Атмел, как произвоидетель МК, и подтверждает лишний раз, что они сперва делают, а потом думают.

Тем не менее, учитывая это открывшееся для меня обстоятельство, приношу извинения CD_Eater за свою оценку его высказывания насчет инверсии пинов в AVR. На будущее в целях избежания подобных недоразумений, советую выражаться яснее.

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

tiny2313, 13, 25/45/85, mega48/88/168, 640/1280/1281/2560/2561, 165/325/3250/645/6450, 169/329/3290/649/6490, PWM2,3, может быть, еще какие-то забыл.
Не так уж и мало, и совсем не вчера.

Умножитель в AVR тоже не сразу появился...

Все как один новые. Как быть с остальной частью семейства, коя представляет подавляющее большинство? В любом случае распространять некое свойство некоторых МК на все семейство, мягко говоря, некорректно. И если так делать, то уж всяко надо уточнять, говоря, что в некоторых МК оно есть.

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


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

Аппаратный умножитель ИМХО был стандартной фичей семейства Мега, о чем и говорилось сразу. Причем три основные линии семейства, наследовали друг друга по ядру и IO. На сегодня в AVR полный разнобой - разный мэппинг периферии, разные фьюзы, итп. В одной линейке оказываеться и Tiny13-15 и Tiny26/2313 совершенно различные по идеологии и области применения.
Недавно за отсутсвием М8 купил в новую партию изделий М88 - перепиливал код достаточно достаточно долго.
Вероятно уже начался закат AVR.

Насчёт подавляющего большинства - не согласен. Смотрите:
[attachment=6191:attachment]
Практически половина чипов. Все новые (относительно, год-два), тем не менее, скажем, все наши устройства уже переведены на них.
Вторая половина - почти вся устарела. А дальше - устареют и оставшиеся.



Снова не согласен. Атмел просто перешел от отображения специализации в названии к отображению более мелкой специализации в номере чипа. Другое дело, что можно было сразу с этого начать
С этой точки зрения tiny2313 и 26 - разные линейки, а 25/45/85 - одна.
И с периферией с новых чипах значительно приятнее работать - её больше, она функциональнее и удобнее. Регистры совместимы в пределах линейки, опять же.

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

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

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