Assembler или С?

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

 

Спасибо всем огромное!

 

Ну мое мнение...

Стали делать много мк с кучей вкусностей и горой флэша и озу... Там где можно поставить attiny13, мы лепим какой мк с 32 ногами и горой флэша..Там где нужно 1 кб флэша под код, мы лепим 8 кб... Ну это например.. Не умею красиво выражаться..

Мы забыли про оптимизацию... Если нам мало 8 кб, мы лепим 16 и выше.. При этом код растет и растет..

Мне нравится писать на асме, так как можно сделать красиво, избежать не нужных конструкций, сделать реализацию по минимуму...

 

Код на асме ужимается примерно в 2-3 раза от аналогичного кода на си. Единственно у всех мелких контроллеров ограниченно выводов. Бывает делаешь что на attiny13, осталось 512 флэша свободного, а ног нету, и не придумать ни чего...

Обычно у 13 делаю так, ставлю 595 на 3 ноги, для вывода информации дисплей, 7 сегментник например, управления чем либо - реле, мосфеты итд. А на остальные 3 ноги вешаю кнопки, какие входные сигналы..

 

МК все дешевле, а жизнь все короче. Если не на спор нужно упихать задачу в Тини 13, то можно быстрее и камфортнее сделать на Меге 8, то почему бы нет? Да хоть на STM32, теперь и это стоит копейки при несравненно больших ресурсах. Я за против излишнего перфекционизма и мазохизма.

 

Не забываем, что компилятор C/C++ оптимизирующий. В большинстве случаев он сгенерит более оптимальный код (по объему, производительности и т.д.), чем может сделать человек программируя на ассемблере. Ну наверное кроме самых маленьких задач.

Хороший подход - собрать код, экспериментально выявить "узкие" места, посмотреть ассемблерный код этих мест, который порождает компилятор C/C++, взять его за основу и поправить.
Чем меньше ассемблерного кода в программе, тем проще будет её сопровождать, дорабатывать, переносить на другие платформы.

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

 

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

 

То вы парня агитируете учить ассемблер, то тот язык в котором побольше сторонних библиотек. В которых неизвестно, что наворочено и оказывается, места катастрофически не хватает. Или библиотеки гуру пишут?
Разбирая некоторые... бывает тихий ужас заставлять несчастный 8ми разрядный контроллер перемножать две 4х байтных переменных ради сравнения с третей, с однобайтной точностью, и говорить не хватает производительности...
Сравнивать С++ и ассемблер, это как экскаватор с лопатой. Ерунда, что медленно зато лопатой ровнее
Писать нужно на чем получается и нравится на том, что удовлетворяет потребности.

 

Кстати, один такой аргумент забыли озвучить, очевидный впрочем...
C/++ он для всех один, а ассемблер у каждой архитектуры свой отдельный,
и никакого такого "ассемблера вообще" не существует.

 

Библиотеки хороши тем, что их использует много людей. Популярная библиотека в итоге будет лучше проверена, отлажена и задокументирована. А не нравится библиотека, не используй её. Поищи лучше или сделай свою.

 

Это языка не касается, это другое измерение так сказать...

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

 

Для абстрагирования от особенностей периферии (Hardware Abstraction Layer) есть условная компиляция и более или менее "стандартные"/популярные библиотеки. Оно есть и для ассемблера и для C. В худшем случае компоненты HAL придется реализовать самостоятельно. В противном случае получится программа которую проще будет заново написать под новый МК, чем портировать.