Написал сначала проект на ASM в AVR Studio, а позже очень похожий на Си. И там и там вылизывал по скорости. Точнее особо не вылизывал. В обоих случаях камни с большим запасом. Естественно во втором проекте было всё намного грамотнее построено. Вопервых дробление шагов на основе ШИМ с большим коэффициентом, во вторых более красивое движение стрелок обеспечено. 18 скоростей с плавным переключением. Фильтрация более красивая. Обработка CAN некоторое место занимает. Тем не менее сравнивать можно

Результаты достаточно любопытны для неопределившихся. Попробовал свести в небольшую таблицу.


Несколько попозже буду перетаскивать Этот проект на м8. То есть можно будет сопоставить практически 1 к 1 (с учётом значительных улучшений).

Для меня лично есть одно НО:
вот я использую мультипоточное программирование на асме, стек-фреймы и прочее - так проще и читабельнее выглядят программы. Диспетчеризация кооперативная. При переходе от потока к потоку в свопинге участвуют только содержимое PC и SP. Все крутится на минимальном наборе регистров, потому что большая их часть задействована в прерываниях, в которых тоже свопинга мало. И под такую Homebrew - ось я заточить "С" не смогу никак.
Вот вчера запустил ногодрыгалку на меге 640 по теме, которой я к Вам в личку напрашивался.
Из 15 возможных ШИМ используются все с частотой до 10кГц.
Из 16 АЦП используются все.
+ Дисплей 7 сегментный + клава + 2 модбаса + 1 RS232.
И рад бы я это на "С" написать, потому как времени на это немного, но прикинул, что с учетом неперенесенных наработок и определенной критической массы Time-critical sections, да еще и трудностей с мультипотоком, писанины будет раза в 3 больше.

А тут же параллельно силовая поделка на:
пульт на меге 8 (+модбас)
контроллер: мега48+PIC18f2431 общаются по I2C (+модбас)
Здесь без "С" вообще никуда.

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

Это все не показатель.
Если код на С заточить например под IARовский компилер и использовать его фичи:
#pragma inline=forced
__z
__z_x и т.д.
посмотреть как компилятся определенные конструкции
у меня например есть макросы работы с кольцевым буфером в 256 байт выравненым, которые компилятся в


использовать временные перменные


можно получить код не хуже чем на асме!
зато с большими функциями в которых используется много указателей и вычислений гемора не будет
(IAR прекрасно пересылает указатели movw ZL:ZH, .....)

2 _pasha.
Да с наработками не хочется расставаться - согласен.
И, на небольшом проекте, действительно объём проги на ASMе меньше чем на Си. Особенно если писать грамотно.

Но вот такой вот пример. У меня там фильтрация цифровая есть, так вот при переходе с 8-ми битного режима АЦП на 10-ти битный изменилась:
1) Одна константа (KADMUX)
2) В двух местах заменил ADCH на ADC
3) После фильтрации сигнал поделил на 4. ((z0>>2)&0xff)

И всё!!!
Чтобы коэффициенты 16-ти битные были заменил одно объявление int8_t на int16_t.

На Си мне не приходится собираться с мыслями, чтобы решиться на координальную переделку проекта. Switec-овский алгоритм осилил за час

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

Извиняюсь за оффтоп, но что такое "Switec-овский алгоритм"?

Красивый алгоритм управления стрелками на ШД. Он обеспечивает плавность движения стрелок. Задача, на самом деле довольно сложная. Я реализовывал упрощённую модель.

Смысл в том чтобы плавно менять скорость движения стрелки в зависимости от ошибки по положению.

ИМХО. Написать С код соизмеримый с асмом можно, но требует таких же трудозатрат.

А вот интеретно, использовали ли Вы такие приёмы?

В первый раз подобное слышу (обычно народ жалуется, что наоборот).
Наверное потому, что оптимизацию никогда не выключаю.

...если толком не писал ни на том, ни на другом.

Дык это совершенно правильный код для помогания компилятору. В общем случае структура любой функции для камня с большим количеством регистров должна стремиться к такому виду:


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

А что такое стек-фреймы?
Меня первый же безусловный переход вводит в ступор, а второй - в ярость.
Это я так, нисколько не собираясь споров затевать.

Ну, я сразу все не напишу.
Модель вкратце, остальное по уточняющим вопросам.


Это по данным.
Предположим, у нас уже Y адресует начало этого блока данных
Тогда пролог процедуры:

Эпилог соответственно восстанавливает все обратно
Очень полезный макрос

Итого в нашу пользу:
1. Имеем реентерабельные процедуры. Могу выложить пример, где 4 одинаковых процесса крутятся таким образом, выдают инфу каждый на свой индикатор (7-сегм), обрабатывают энкодер как орган управления (правда, плохонько, но претензий нет, я и не работаю над собой)
2. Читабельность зашкаливает
Вместо приснопамятных переменных State мы переопределяем точку входа в процедуру.
Что-нить проверили, кое-какое условие, затем просто пишем leave addr вместо rjmp


3. Если глубина локального стека позволяет, можно вызывать другие подпрограммы, и если в них использовать leave, все еще интереснее. Т.е. с точки зрения программиста нормальная логика выполнения программ не нарушается.
4. Локальные данные адресуются с помощью yL:yH, намертво закрепленных за указателем
Продолжать ?

Нет, спасибо.
Интересно, конечно, но я уже перешел на 'C' и возвращаться не имеет смысла.
Однажды видел проект (система продажи билетов на ЖД эпохи начала перестройки), в котором использование макросов и условной компиляции поражало воображение, но для этого нужна свежая молодая голова.
Too late

Извиняюсь, не могу смолчать.
1. У меня голова уже точно не молодая и не свежая - сын в институте...
2. У атмелов-то правильных макросредств только недавно появилось

3. Немножко все-таки продолжу про минусы того,чего написал выше.
Главный минус - это как детский вопрос : "Можно ли прикрутить туда 1-wire ?"