Сравниваем программы написанные на С++, С и Assembler. Смотрим по скорости выполнения программного кода и по объему занимаемой памяти. Текстовую версию можно посмотреть на сайте: texnohelp.com/assembler-0/
Хорошо, что Вы решили поднять эту тему. Сам пишу только на Асемблере, при отладке программы хоть понимаешь, что откуда взялось. Не пинайте сильно, я не волшебник, я только учусь!
Здесь все зависит от целей, если Вам надо температуру мерять плиты и выключать ее в нужное время - можно и на С++ написать: быстро, не парясь и результат. Но если Вы управляете какой то серьезной системой от которой зависит жизнь людей - тут уже надо максимальное быстродействие, и заморочка с Assembler-ом оправдано.
да, согласен с автором. А то как-то смотрел видос, там один "знаток" делал "змейку" на ассемблере.... видео шло несколько часов, за которые он только интерфейс слабал(!)... Я когда понял, что с концом видео игра ещё даже не начата, подумал "йоптваю так писать до пенсии будешь"))
Ассемблер полезен в работе на низкоуровневой логике работы компьютера, т. е. взаимодействие программно-аппаратного уровня. Все равно, когда вы пишете программу на высокоуровневом языке, он компилируется в машинный код близкий к машинному. Ассемблер имеет наиболее близкий код к машинному, но писать на нём дольше программы, а это время и деньги, но выполнение кода будет быстрей, а программа по весу меньше. Но сейчас такие мощности у машин, что они нормально справляются с программами на высокоуровневых языках, которые позволяют писать программы быстрей и дешевле. Ассемблер ещё хорошо помогает в программном инжиниринге. Но по мне, лучше смотреть в сторону оптимизации кода и работать над эффективностью использования памяти самой программой и её адаптации.
@@JonSonMus раньше было актуально писать на ассемблере, на спектруме например, процессор 3 Мгц и нет видео чипа . Там хочешь не хочешь ,а писать надо было на ассемблере игры, что бы они хоть как-то были плавными и играбильными более мение )
Как приятно, когда человек говорит о ассемблере для AVRок. Сам пишу исключительно на ассемблере. Кто говорит, что писать там долго, сложно, заморочисто - ничего подобного. Составили и нарисовали нормальные алгоритмы каждого блока программы на листе бумаги, а потом только стучи по клавишам. Намного всё понятней и проще всяких Си с их библиотеками. Я уж думал, что AVR да, ещё и на асме, отмирает. Взялся осваивать STM32 пару дней назад - даётся тяжело. А так, на Атмегах с использованием ассемблера можно много что наворотить. Зато чувствуется полнейший контроль над железкой. Как захочешь, так себя и поведёт - вплоть до такта.
@@endlessvd Он проще да - проще в плане написания кода (так сказать - более очеловечено). Когда имеется поняти, как там всё работает, на уровне ТТЛ и КМОП, границы непонимания стираются на прочь. Ассемблере, как раз, к этому располагает. И поверьте: если Вам нормально объяснить, как писать на ассемблере - Вы его полюбите)
да тут одни спецы в асме собрались.. тоже читаю и ржу... ограничение асма пожалуй только при необходимости вещественных вычислений... да и то если нужна точность до 5-знака после запятой и более... сетевые какие нить протоколы на асме умрешь писать... все остальное как правило пишется легко... просто редакторов на асм банально нет... а уж стандартные задачи которые пишутся на ардуино кладутся на асм проще простого...
Если уйти от Ардуино и использовать взрослые IDE для написания программ на С/С++, то настраивая режимы оптимизации компилятора, мы получим почти такой же эффект, как от написания кода на ассемблере, а в некоторых случаях и лучше!
Вообще, для низкоуровневой разработки под AVR (особенно на ассемблере) лучше подходит AVR Studio. Там есть поддержка самых разных чипов, а так же встроенный отладчик с симуляцией.
Ну тут именно по размеру неправильно сравнивать, так как там все равно стандартная функция инициализация самого ядра arduino, ну и сами функции в библиотеки имеют кучу проверок, надо было так же на регистрах, используя С\С++, подергать вывод, думаю занимало бы существенно меньше места, а можно ещё оптимизацию компилятора включить и там ещё меньше будет, а так ассемблер полезен, иногда некоторые фишки можно использовать только через ассемблер и поэтому делают ассемблерных вставки, надеюсь это будет в ваших видео, как написать функцию на ассемблере и использовать в Си коде, с аргументами и без
В данном уроке лишь концепция. Те кто хорошо разбирается и так понимает и знает что и как сравнивать. Зачастую многие даже про оптимизацию не знают, именно для них это и делалось.
Ну для каждого свое, но мне кажется нужно хоть что-то поделать на асемблере для понимания как впринципе работает один из самых низких уровней пк. Хотя я ленивый и до сих пор, даже чтобы удолить свой интерес, так и нечего не сделал на асемблере и даже бонально его не изучал.
Всё не настолько плохо. Там вроде в среде ардуино 2 команды делаешь-занимает 700, 100 команд-занимает 800 например. Т.е. сам факт того что в среде этой пишешь сразу накидывает какое-то фиксированное количество занятой памяти, а потом в зависимости от количества кода суммарная занятая память растёт очень медленно.
Я не говорю, что надо писать только на ассемблере, как реализовать данный алгоритм без потерь производительности с минимальными проблемами я знаю, и у меня так же есть уроки. А на чем писать - это Ваш выбор.
У меня тоже инженеры любили на низком уровне писать) когда стал платить за конкретную работу сразу перешли на freertos , сразу перестало все тупить и тормозить. На низком уровне сейчас в принципе нельзя что-то путное написать.
Я даже не знаю что Вам ответить, нет команд на AVR, есть команды ассемблера, какие то поддерживаются определенным МК, какие то нет. Ну и знание внутренности МК, какие регистры есть, и т.д.
ооо, еще один любитель заговоров ))). Современные подходы и задачи на ассемблере люди просто не сделают, там и объемы программ огромные и функционал огромен. Да повышают частоты, но благодаря современным высокоуровневым языкам много чего создали уже, чего на ассемблере не создали бы никогда. Например современный тяжело нагруженный сервак банка на ассемблере писать или современную 3Д игру или чертежный софт 3Д и т.д. - это может и жизни не хватить, не говоря уже если что то нужно поменять, когда как с том же С++ или Java всё делается в разы проще и удобнее, на то он и придуман язык более высокого уровня с классами, ООП и т.д. Для космоса, медицины, оружия и т.д. ассемблер спору нет, и то там только для сильно ответственных узлов, где нужно выжать максимум из железа, а для задач обычного пользователя писать программу на ассемблере это как примерно строить дом с замерами микрометром, что не адекватно. Во многих случаях проще поднять частоты и пользоваться С++ или даже микро Питон, и в итоге и проще найти работника и порог вхождения ниже для разработки приложений и проекты нормально работают и большинство будут довольны. Во многих задачах бытовых дешевле поднять частоту, чем обучать толпу людей ассемблеру и в итоге и ошибок буде в разы больше, для этого и был создан С, потом С++ и т.д., когда автоматизация основных процессов в том же С++ позволяет избавится от сотен детских ошибок, но минусом будет потеря скорости работы программы, которую нивелируют поднятием частоты работы процессора. Да и с развитием IT уже видно, что код скоро будет писать ИИ и будет писать его идеально.
@@TheVovaDen Уже видно, как ИИ пишет код. Только не показывают, как этот код потом люди правят. Джунов ИИ уже может заменить, что будет дальше - никто не знает.
@@AlexanderRozhkov_ Согласен. Но, если при одинаковом потреблении энергии периферией то программа на ассемблере будет потреблять меньше энергии (из-за меньшего объема) чем программа, написанная на высокоуровневом языке.
вооот!!! а теперь, кто будет "возникать" против ассемблера, расскажи про драйверы... Там уже без регистров и ассемблера не обойдёшься...Да и с плюсами столько "косяков" что лучше их обходить стороной.
Знать очень полезно. Писать на нём особо нет смысла. Только вставки и критические участки. На нём сейчас актуально писать под DSP, и всякие VLIW архитектуры. На этом, пожалуй, всё.
Круто. Но ассемблер потому и был вытеснен языками высокого и сверхвысокого уровня, что в них разберется почти любой. В то время как работа с ассемблером очень трудоёмкий процесс (если это не простая генерация 0 и 1).
Фанаты асемблера меня всегда поражали своей упертостью. Если им нравится садомазо, я не могу их лишать этого удовольствия. Кроме того вы вопиюще неправильно используете МК, т. к. для генерации частоты уже дцать лет есть аппаратный PWM!!!
Это не генерация шим, а демонстрация концепции разных подходов. Не кто не кого не заставляет писать на Асемблере, у каждого свой путь и свои предпочтения.
я не особо знаток, точнее вообще не знаток, но вызывая в языке С++ например, кем то написанную функцию непонятно как оптимизированную и написанную с применением неизвестного подхода к программированию, говорить, что мол посмотрите 700 байт на этом языке программа требует - не особо корректно. Нет я ни в коем разе не утверждаю, что с++ удобнее для программирования встроенных систем, но практически уверен, что при наличии знаний и навыком расписать данную программу можно гораздо эффективнее и на нем, не говоря уже про Си. Поправьте, если ошибаюсь.
Функцию которую я вызываю, это именно встроенная функция Arduino IDE, а не написанная кем то. Если вы пишите код для измерения температуры и включения/выключения реле, то С++ самое то. Но если Вы пишите код которых контролирует безопасность человека, то в данном случаи С++ как то не очень. Но все зависит от ваших требований и знаний.
@@AlexanderRozhkov_ возможно встроенная функция написана разработчиками Arduino IDE, ну или еще кем-то она однозначно написана. Может даже данный подход и не подразумевает, что ему можно доверять жизни людей. Ну а в общем, конечно бесспорно то - что у каждого инструмента есть своя область применения, для которой он лучше всего подходит.
В ассемблерной версии выкинута инициализация векторов прерываний, что не есть хорошо, отсюда и такой маленький размер. Да и стёк надо бы правильно инициализировать, а не оставлять в каком попало состоянии.
@@Alexander_Gurov_RF _По русски "стёк", по английски "stack_ - по-русски *стёк* имеет лишь две формы - существительное и глагол. В первом случае это означает *водосток* , а во втором случае - прошедшее время завершённого процесса стекания чего-либо. Иных смыслов данное слово не имеет! Соответственно им (словом "стёк") неправильно называть линейную списочную структуру данных, которая в английском языке имеет название *stack* *Учим матчасть!*
Assembler знать полезно, но писать на нем... Хотел бы я посмотреть, как вы напишите программу, где происходит опрос нескольких датчиков с разными протаколами обмена данными, оброботка по разным алгоритмам и выводом этих данных на графический экран, а потом, когда выяснится что нехватает ножек или памяти(или просто негде взять нужный МК) у выбранного микроконтроллера, перенести эту программу на другой микроконтроллер. Язык Си общепринятый стандарт для микроконтроллеров, а в ответственных по скорости участках используют ассамблерные вставки.
Если проект сложный то вы в своем ассемблере так напутаетесь и ошибок наплодите столько что код будет мало того как портянка здоровый да и к томуже кривее всех кривых и времени затратите на это тонну, а время это ценный ресурс
@@AlexanderRozhkov_ я не говорю что он не нужен, он нужен и на необходимом мне уровне я его знаю, я говорю что обвинение плюсов не оправданы, обвинять нужно ардуиновские либы
вы совершенно не понимаете, что такое языки программирования. про с++ и с очень интересно 😂😂. а еще вы очень удивитесь, когда замените setup() на int main() и сравните занимаемую память
@@AlexanderRozhkov_ да просто как то не совсем корректно получается, в ардуино когда пишешь определение ноги под капотом срабатывает макрос, что туда прописал в определении автор так оно и подстааляется
У меня не было цели кого то мотивировать, а лишь показал различия. Выбирать Вам. Если Вам надо управлять включением/выключением вентилятора в зависимости от температуры - конечно на С++ быстро написали и готово. Но если у Вас система которая отвечает за быстродействие или безопасность человека - явно надо немного другой подход чем С++. Ну и наверное Вы не писали огромные программы где у Вас вся периферия занята, процессы быстродействующие и каждый байт на вес золото.
@@AlexanderRozhkov_ _наверное Вы не писали огромные программы где у Вас вся периферия занята, процессы быстродействующие и каждый байт на вес золото._ Точно... Не писал... люди которые *такое* пишут не будут смотреть видео из рубрики "урок№0.." и т.д. Стоимость разработки программы для микроконтроллера на асике была актуальна когда микроконтроллер стоил адских денег. сейчас можно позволить себе купить ведро микроконтроллеров за такие деньги и сделать опрос каждого датчика отдельным чипом. ИМХО конечно...
@@AlexanderRozhkov_ Огромные программы, будь-то операционные системы, движки для игр/симуляторы, встраимоевое ПО для робототехники где трубуется большое быстродействие не пишится на асемблере так-то а вот на С++ сколько угодно.
@@sencis9367 _встраимоевое ПО для робототехники где трубуется большое быстродействие_ Людям которые смотрят "урок №0" до робототехники - как до луны... а до операционных систем - как до юпитера... К чему это я...!? К тому что обычному домашнему-"программисту" - ассемблер не нужен от слова - совсем. Под каждый камень - изучать по новой 200страниц даташита - естессно такой человек читать не будет. А скорость камней выросла так - что в принципе уже не особо важно на чем пишется ПО. Для времен камня 8080 - это было критично. А сейчас купил ESP32 - и за глаза.. хоть на бейсике пиши... завалить этот камень обычной бытовой задачей - трудно... Впрочем не важно... все равно с ассемблером все закончится у вас "уроках" на 5 от силы...
@@user-cf7be9km5m Может и нет, иногда бывают сложные задачи в которых потребуется объединить информацию из 10ка различных туториалов, что-бы достичь результатов. Например при обработке радиосигналов на микроконтроллере иногда требуется решать задачи фактически в реальном времени, информации с камеры (визуальной однометрии) хотя конечно её лучше вынести на более мощные вычислители но микроконтроллер дешёв а объедение данных с imu частично компенсирует этот недостаток за счёт интеграции измерений от камеры в инерциальных измерениях. Но это всё именно не большие программы, просто частоты их вызова большие данных много.
чем вам ардуина не угодила ? если ее выбрасывать то давайте и HAL выкинем в армах, и LL... будем все на cmsis на си писать 🙂 не понимаю этих тупых холиваров... ардуина это просто набор библиотек взаимодействия с периферией.... и все равно как эти либы будут называться....
