Просто остались люди, которые как неандертальцы, исповедуют до сих пор ассемблер, но не православный чистый, а макросо-наваленый. Это довольно-таки тупиковая ветвь эволюции в нашем 2025-м году. Да че там говорить, даже чистый Си уже мало удовлетворяет. Хотя, новый стандарт Си добавил плюшки из С++, но они как-то противоестесственно смотрятся.
Для микроконтроллеров сейчас самое то - С++. Исправляет недостатки Си и генерирует вполне себе компактный код. Конечно, если уметь писать на нем.
Чистый Си - язык очень простой, и по-моему, проще ассемблера.
Да, в нем нет "команды чтения и подавления дребезга кнопок". Но и в ассемблере её тем более нет! Язык программирования - он универсален, это инструмент, которым можно и гвоздь забить, и фигурку вождя революции вырезать.

КотПротон, Абсолютно поддерживаю. Грамотная программа на си в большинстве случаев , на 20-30% больше по размеру грамотной ассемблерной. Но скорость написания и отладки - гораздо выше.

вроде, я уже где-то писал про свой проект загрузчика, но еще раз расскажу.
когда я заинтересовался загрузчиками я нашел загрузчик с сайта chip45. он написан на Си и для АТмега8 размер имеет около 1700 байт (точно уже не помню, так как удалил его).
потом я сделал полный аналог этого загрузчика на ассемблере и мой загрузчик имеет размер 454 байта.
разница в размере примерно в 3,7 раза.
вопрос: а где тут разница в 20-30%? у меня получилась разница в 270%
а может, ты скажешь, что на этой фирме пишут совершенно безграмотно на Си?
и прежде, чем делать аналог, я дизассемблировал оригинал от этой фирмы. и могу сказать, что все "излишества" в длине программы - это самая обычная компиляция с языка Си.

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

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


Кстати, с ИИ сейчас можно вернуться к ассемблеру, получив высокую скорость написания. Я как-то в Грока загрузил спецификацию на МК и попросил его накидать простенькую болванку инициализации, он справился, и лучше, чем пример от производителя.

Со скоростью отладки мне сомнительно, что есть разница, ведь нормальная отладка ведётся по ассемблерному листингу в том числе.

Starichok51, кажется в той теме, где ты этим хвастался, уже обсудили. Ты вырезал из универсального большого загрузчика все ненужное тебе. и получил выигрыш.
Но это частный случай.
А я говорю про среднюю температуру по больнице. Оверхед грамотно написанной программы на ЯВУ против грамотной программы на асме - около 30%.
Nranddek, Нормальная отладка в семействе старых 8-битных АВРок - сложное (а точнее, очень дорогое) удовольствие. AVR Dragon далеко не каждому доступен. А без него лепить программную отладку надо. Это не всегда удобно. Хотя даже я иногда отлаживала изделия на мелких МК ( включая 8-ногую тиню), выдавая последовательные данные на пин со светодиодом и читая их копеешным логгером. Но отладка в железе гораздо более приятна и удобна. и там уже не важно, асм или си.
Однако вопросы отладки не стОит обсуждать здесь, для этого где то на форуме выделена отдельная тема, где собралось много народу, включая AQ29, KPAM-а и других....
Кстати, как и отдельная тема по антидребезгу....

Вот не скажу за AVR, тыщщу лет с ними не работал, но на том же STM компилятор C++ с включенной оптимизацией генерит очень компактный код, который ничуть не уступит ручному написанию на ассемблере.
Вообще, если после компиляции Сишного кода у вас получается слишком большой размер, попробуйте-таки включить оптимизацию компиляции.


ИИ - это просто продвинутый поисковик. И он тоже может ошибаться. Я уже пробовал - зачастую, выдает то, что и не собирается работать.
Так что какой смысл генерить через ИИ ассемблерный текст, если его прекрасно генерит С/С++ компилятор


Хм. Правда?? Вау, да вы крутой погромист! Серьезно. С вашим талантом теперь надо приступить к ассемблерному проганию STM32N6 на ядре Cortex-M55. Я уверен, что на ассемблере вы напишите быстрее, чем кто-либо на С++

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

Nranddek, так вон в рамках частных случаев у некоторых оптимизация 270% достигает.... Но ценой вырезания всего ненужного автору и отказа от универсальности.
Так-то можно зазибовать текстовый файл и зарарить джипег. И доказывать, что зип-архиватор круче, жмет лучше.
Но если у вас есть желание поспорить про отладку или про антидребезг кнопок - велкам в соответствующие ветки форума, их есть тут.

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

Starichok51, не хочу холивар сюда тащить, но кажется ты писал, что ограничил функционал только для используемых тобой трех видов контроллеров.
И, опять же, ты крут, если любой проект на си ужмешь на асме в 270%
А если частный случай, то исключения только подтверждают правила.

не надо путать функционал загрузчика и загрузчики для разных видов контроллеров.
да, у той фирмы существуют загрузчики для большого количества контроллеров, но функционал загрузчика всегда одинаковый.
а я сделал загрузчики для 4 типов АТмег: 8, 88, 168, 328 - типов, наиболее популярных.
количество поддерживаемых типов контроллеров не имеет никакого отношения к функционалу загрузчика.случай не частный. где-то я тоже упоминал про некоторые функции для плавающей точки.
в частности, чтение числа из строки и вывод числа в строку у меня на ассемблере получились тоже в несколько раз короче.
а математика - сложение, вычитание, умножение и деление - там выигрыш маленький. но все равно и в математике там много лишних операций с пересылками между регистрами "туда и обратно". а в чистом ассемблере эти пересылки не нужны вообще.

Добавлено after 7 minutes 14 seconds:
хотя да, соглашусь, что 270% для загрузчика - частный случай. всё зависит от программы.

У вас сравнение идёт с обычным ассемблером, а «не православно чистый» ассемблер – это другой уровень, писать гораздо проще, есть там и встроенная «команда чтения кнопок с подавлением дребезга».
Насчёт универсальности языка тоже сомнительно. Вроде как полно разных языков, «заточенных» под разные цели. СИ сделали для больших процессоров, а у МК параметры совсем другие, наверно, нужен свой язык. Насколько представляю, СИ приспособили для МК, но по быстродействию он слабоват супротив ассемблера. Сделали ассемблерные вставки, а это вроде как костыли. Язык с инвалидными костылями не впечатляет.

Интересно, откуда взялись цифры 20-30 %. Наверно, сравнивали какие-нибудь небольшие участки кода или простые программы, это просто сделать и получить совсем небольшое увеличение. Но для объективности надо сравнивать большие сложные программы, написанные профессионалами, а кто будет таким специально заниматься.
В этом плане интересен пост от Starichok51, у него как раз такое сравнение, результат существенно другой.
Скорее всего, есть зависимость от типа программы. Тогда цифры 20-30 % - чисто рекламный слоган. По результатам обсуждения для объективности надо дописать, что реально у вас может получиться и 270 %. А чтобы существенно снизить эту цифру, надо долго и упорно трудиться над «вылизыванием» кода, скорее всего, на ассемблере написать быстрее.

Когда то элементарный блинк соревновались писать на Си. Как бы не в 16, или даже 10 байт укладывались. Разницы с ассемблером нет. Всё зависит от писателя. Ну и допускаю, что на сложном софте у Си может быть даже преимущество в размере. За счёт оптимизатора.

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

Может, он оптимизировал не по объёму занимаемой памяти, а по скорости выполнения ?

Даже если явно указывать оптимизацию по размеру (-Os в gcc)?
Кстати, размер программы после оптимизации зависит от версии компилятора. В своё время (2010) пытался впихнуть очень сложную программу для 10-разрядных часов в М8 - на компиляторе тех времён прекрасно получалось, а через пять лет компилировал на более новом - порядка 200 байт лишних, пришлось вырезать часть функциональности, а затем переходить на М168.

тут еще может быть такая вещь... компилятор имеет стандарты/соглашения по оформлению программных блоков, по размещению переменных статических, волатильных и локальных, по вызову функций... Это все тоже требует ресурсов флеша.
А асемблерописатель может поужимать код за счет отказа от соглашений, просто помня, что и в каком регистре у него живет. Иногда можно сильно ужаться... Но вот я смотрю свои первые ассемблерные программы, где я тоже пыталась оптимизировать все и вся.... Нублин, там же черт ногу сломит.... Даже с комментариями... А если принять какие то соглашения в оформлении подпрограмм, их вызове, передаче параметров, в хранении переменных и следовать им, то уже код получается более структурный.. Но не такой компактный и запутанный. Да, он меньше сишного. Но на сях легче писать. И быстрее.

Ну и я скажу еще пару мыслей:
- когда все построение микроконтроллерных устройств ограничено тинями и мегами - то можно писать на асме. А когда добавляется еще пара других семейств с другой архитектурой - то приходится или учить еще ассемблеры, или таки переходить на ЯВУ. И никакой переносимости кода. (Да и я себе не представляю, как и сколько времени нужно писать на асме и потом отлаживать код размером 100-300-500 кб).
- при нонешних объемах ресурсов экономить флеш не всегда рентабельно... Ну вот есть М8 - на си программа - 7 кб, на асме - 5 кб. Новый функционал не предвидится. Толку от более компактного кода? Куда девать сэкономленные 2 кб флеша? Быстрее работает? Так все равно 95% алгоритмов предусматривают какую то временнУю синхронизацию - просто МК чуть больше времени проведет в цикле ilde...
Оптимизация и переход на асм хороши в специальных случаях... уложиться в какой то сегмент флеша (бутлоадер), критчный ко времени исполнения блок кода с четко прогнозируемым временем выполнения...

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

Это если -o3 и при этом этот самый "о" не глючит. Видел я разное в этом мире.

Не следует перегибать и гипертрофировать до абсурда. ЯП следует выбирать исходя из разных параметров. Например, простые системы где всё можно держать в голове или иметь быстродоступную подсказку лучше писать на ассемблере. Да, придется уметь в разные алгоритмы, но тыжпрограммист или покурить вышел? А вот сложные системы лучше программировать на более высоких языках. Сам лично С не считаю ЯВУ, по мне он как макроассемблер со своим синтаксисом. Но он точно повысит скорость написания программ на процессоре 32 бита. Ну а говнокодить можно на любом языке, даже на ванильном ЯВУ BASIC.

вот именно. именно это и раздувает длину кода.вот именно.вот именно. поскольку для моих домашних нужд больших программ не надо (самый длинный код у меня менее 4,5 кБ), то мне не в тягость писать на ассемблере.
а если бы требовался объем в десятки или сотни килобайт, то и я не стал бы писать на ассме.

Был у меня один проектик на асм. Лет 10 писал, ещё лет 10 поддерживал. 36000 строк. Вся молодость ушла.(