Урок №0. Почему важно уметь программировать на языке Assembler.
ฝัง
- เผยแพร่เมื่อ 5 ม.ค. 2023
- Сравниваем программы написанные на С++, С и Assembler. Смотрим по скорости выполнения программного кода и по объему занимаемой памяти.
Текстовую версию можно посмотреть на сайте: texnohelp.com/assembler-0/ - วิทยาศาสตร์และเทคโนโลยี
![บุกร้านไอศกรีม VJ วุ้นเส้น !!!! [ดูคลิปเต็มหน้าช่อง] #Short | PANG ORNHIRA](http://i.ytimg.com/vi/g549nEhKZdc/mqdefault.jpg)
Спасибо за Ваш труд! Здоровья Вам и долголетия!
Спасибо за труд!
Да, ассемблер надо изучать, но пока я его изучу то состарюсь и забуду всё, что учил! :)
Спасибо за Ваш труд
Спасибо за урок!
Хорошо, что Вы решили поднять эту тему. Сам пишу только на Асемблере, при отладке программы хоть понимаешь, что откуда взялось. Не пинайте сильно, я не волшебник, я только учусь!
Здесь все зависит от целей, если Вам надо температуру мерять плиты и выключать ее в нужное время - можно и на С++ написать: быстро, не парясь и результат. Но если Вы управляете какой то серьезной системой от которой зависит жизнь людей - тут уже надо максимальное быстродействие, и заморочка с Assembler-ом оправдано.
да, согласен с автором. А то как-то смотрел видос, там один "знаток" делал "змейку" на ассемблере.... видео шло несколько часов, за которые он только интерфейс слабал(!)... Я когда понял, что с концом видео игра ещё даже не начата, подумал "йоптваю так писать до пенсии будешь"))
Ассемблер полезен в работе на низкоуровневой логике работы компьютера, т. е. взаимодействие программно-аппаратного уровня. Все равно, когда вы пишете программу на высокоуровневом языке, он компилируется в машинный код близкий к машинному. Ассемблер имеет наиболее близкий код к машинному, но писать на нём дольше программы, а это время и деньги, но выполнение кода будет быстрей, а программа по весу меньше. Но сейчас такие мощности у машин, что они нормально справляются с программами на высокоуровневых языках, которые позволяют писать программы быстрей и дешевле. Ассемблер ещё хорошо помогает в программном инжиниринге. Но по мне, лучше смотреть в сторону оптимизации кода и работать над эффективностью использования памяти самой программой и её адаптации.
если асм арма (стм32, вк35) будет интересен - приходите :-)
а тут вам одни теоритики написали :-) на асме никогда не писавшие ничего более мигалки :-)
@@JonSonMus раньше было актуально писать на ассемблере, на спектруме например, процессор 3 Мгц и нет видео чипа . Там хочешь не хочешь ,а писать надо было на ассемблере игры, что бы они хоть как-то были плавными и играбильными более мение )
Надо продолжать данную тему
Продолжать буду, но на это время надо. Пока канал у меня как хобби.
Жду продолжения...
Это очень интересная тема. Вообще хотелось больше узнать про команды , применение библиотек
и ассемблерных вставок в С++.
Если все будет в порядке - сделаю уроки
Для ассемблерных вставок придётся ещё разобраться с gcc-шными констрейнами. 😅
А можно подобные уроки по С++, все таки объектно ориентированный подход полезно знать
Для всего нужно время. Направления С++ тоже буду по не многу описывать.
ООП на avr?!
C++ - это далеко не только ООП, а ещё и метапрограммирование, что очень полезно. Поскольку оно в компайл-тайм.
очень интересно
Если уйти от Ардуино и использовать взрослые IDE для написания программ на С/С++, то настраивая режимы оптимизации компилятора, мы получим почти такой же эффект, как от написания кода на ассемблере, а в некоторых случаях и лучше!
Как приятно, когда человек говорит о ассемблере для AVRок. Сам пишу исключительно на ассемблере. Кто говорит, что писать там долго, сложно, заморочисто - ничего подобного. Составили и нарисовали нормальные алгоритмы каждого блока программы на листе бумаги, а потом только стучи по клавишам. Намного всё понятней и проще всяких Си с их библиотеками. Я уж думал, что AVR да, ещё и на асме, отмирает. Взялся осваивать STM32 пару дней назад - даётся тяжело. А так, на Атмегах с использованием ассемблера можно много что наворотить. Зато чувствуется полнейший контроль над железкой. Как захочешь, так себя и поведёт - вплоть до такта.
Мне страшно читать, что ассемблер проще си или си-+
@@endlessvd Он проще да - проще в плане написания кода (так сказать - более очеловечено). Когда имеется поняти, как там всё работает, на уровне ТТЛ и КМОП, границы непонимания стираются на прочь. Ассемблере, как раз, к этому располагает. И поверьте: если Вам нормально объяснить, как писать на ассемблере - Вы его полюбите)
да тут одни спецы в асме собрались.. тоже читаю и ржу...
ограничение асма пожалуй только при необходимости вещественных вычислений... да и то если нужна точность до 5-знака после запятой и более...
сетевые какие нить протоколы на асме умрешь писать...
все остальное как правило пишется легко...
просто редакторов на асм банально нет...
а уж стандартные задачи которые пишутся на ардуино кладутся на асм проще простого...
@@endlessvd проще.
А продолжение будет?
Ну тут именно по размеру неправильно сравнивать, так как там все равно стандартная функция инициализация самого ядра arduino, ну и сами функции в библиотеки имеют кучу проверок, надо было так же на регистрах, используя С\С++, подергать вывод, думаю занимало бы существенно меньше места, а можно ещё оптимизацию компилятора включить и там ещё меньше будет, а так ассемблер полезен, иногда некоторые фишки можно использовать только через ассемблер и поэтому делают ассемблерных вставки, надеюсь это будет в ваших видео, как написать функцию на ассемблере и использовать в Си коде, с аргументами и без
В данном уроке лишь концепция. Те кто хорошо разбирается и так понимает и знает что и как сравнивать. Зачастую многие даже про оптимизацию не знают, именно для них это и делалось.
Весь мир опенсурс если знаешь асм=D
@@CoBaldrахаха
Ну для каждого свое, но мне кажется нужно хоть что-то поделать на асемблере для понимания как впринципе работает один из самых низких уровней пк. Хотя я ленивый и до сих пор, даже чтобы удолить свой интерес, так и нечего не сделал на асемблере и даже бонально его не изучал.
Вообще, для низкоуровневой разработки под AVR (особенно на ассемблере) лучше подходит AVR Studio. Там есть поддержка самых разных чипов, а так же встроенный отладчик с симуляцией.
Всё не настолько плохо. Там вроде в среде ардуино 2 команды делаешь-занимает 700, 100 команд-занимает 800 например. Т.е. сам факт того что в среде этой пишешь сразу накидывает какое-то фиксированное количество занятой памяти, а потом в зависимости от количества кода суммарная занятая память растёт очень медленно.
Я не говорю, что надо писать только на ассемблере, как реализовать данный алгоритм без потерь производительности с минимальными проблемами я знаю, и у меня так же есть уроки. А на чем писать - это Ваш выбор.
Тема интересная, но непонятно как делать на ассемблере более сложные вещи: управлять экранами, или расчитывать логарифм для терморезистора.
Я сейчас оооочень занят, надеюсь все поправиться и я сделаю уроки как все подключать и считать.
А как найти документацию по ассемблеру для МК renesas ядро от motorolla?
Тут я Вам врятли смогу помочь.
@@AlexanderRozhkov_ как такой документ может называться? Вы команды на avr где брали?
Я даже не знаю что Вам ответить, нет команд на AVR, есть команды ассемблера, какие то поддерживаются определенным МК, какие то нет. Ну и знание внутренности МК, какие регистры есть, и т.д.
@@AlexanderRozhkov_ ну вот и интересно как искать документы по ассемблеру на конкретный МК?
И вы встречали ретранслятор с языка ассемблера в С код?
перейти с ассемблера на С, проблем нету, мне не совсем понятно, что именно Вам нужно. По ассемблеру есть список команд они доступны в интернете.
А ничего, что у каждого процессора ассемблер свой? Заново учить Ассемблер при переходе на новое семейство процессоров?
Каждый выбирает свой путь.
Assembler знать полезно, но писать на нем...
Хотел бы я посмотреть, как вы напишите программу, где происходит опрос нескольких датчиков с разными протаколами обмена данными, оброботка по разным алгоритмам и выводом этих данных на графический экран, а потом, когда выяснится что нехватает ножек или памяти(или просто негде взять нужный МК) у выбранного микроконтроллера, перенести эту программу на другой микроконтроллер. Язык Си общепринятый стандарт для микроконтроллеров, а в ответственных по скорости участках используют ассамблерные вставки.
У меня тоже инженеры любили на низком уровне писать) когда стал платить за конкретную работу сразу перешли на freertos , сразу перестало все тупить и тормозить. На низком уровне сейчас в принципе нельзя что-то путное написать.
я не особо знаток, точнее вообще не знаток, но вызывая в языке С++ например, кем то написанную функцию непонятно как оптимизированную и написанную с применением неизвестного подхода к программированию, говорить, что мол посмотрите 700 байт на этом языке программа требует - не особо корректно. Нет я ни в коем разе не утверждаю, что с++ удобнее для программирования встроенных систем, но практически уверен, что при наличии знаний и навыком расписать данную программу можно гораздо эффективнее и на нем, не говоря уже про Си. Поправьте, если ошибаюсь.
Функцию которую я вызываю, это именно встроенная функция Arduino IDE, а не написанная кем то. Если вы пишите код для измерения температуры и включения/выключения реле, то С++ самое то. Но если Вы пишите код которых контролирует безопасность человека, то в данном случаи С++ как то не очень. Но все зависит от ваших требований и знаний.
@@AlexanderRozhkov_ возможно встроенная функция написана разработчиками Arduino IDE, ну или еще кем-то она однозначно написана. Может даже данный подход и не подразумевает, что ему можно доверять жизни людей. Ну а в общем, конечно бесспорно то - что у каждого инструмента есть своя область применения, для которой он лучше всего подходит.
Круто. Но ассемблер потому и был вытеснен языками высокого и сверхвысокого уровня, что в них разберется почти любой. В то время как работа с ассемблером очень трудоёмкий процесс (если это не простая генерация 0 и 1).
Согласен, по этому и есть специалисты разного уровня.
вообще не так... но вы же пробовали :-) вам точно можно верить :-)))
Высокоуровневые языки не зря изобретаются для этого повышаются и ресурсы микроконтроллеров
ооо, еще один любитель заговоров ))). Современные подходы и задачи на ассемблере люди просто не сделают, там и объемы программ огромные и функционал огромен. Да повышают частоты, но благодаря современным высокоуровневым языкам много чего создали уже, чего на ассемблере не создали бы никогда. Например современный тяжело нагруженный сервак банка на ассемблере писать или современную 3Д игру или чертежный софт 3Д и т.д. - это может и жизни не хватить, не говоря уже если что то нужно поменять, когда как с том же С++ или Java всё делается в разы проще и удобнее, на то он и придуман язык более высокого уровня с классами, ООП и т.д.
Для космоса, медицины, оружия и т.д. ассемблер спору нет, и то там только для сильно ответственных узлов, где нужно выжать максимум из железа, а для задач обычного пользователя писать программу на ассемблере это как примерно строить дом с замерами микрометром, что не адекватно. Во многих случаях проще поднять частоты и пользоваться С++ или даже микро Питон, и в итоге и проще найти работника и порог вхождения ниже для разработки приложений и проекты нормально работают и большинство будут довольны. Во многих задачах бытовых дешевле поднять частоту, чем обучать толпу людей ассемблеру и в итоге и ошибок буде в разы больше, для этого и был создан С, потом С++ и т.д., когда автоматизация основных процессов в том же С++ позволяет избавится от сотен детских ошибок, но минусом будет потеря скорости работы программы, которую нивелируют поднятием частоты работы процессора.
Да и с развитием IT уже видно, что код скоро будет писать ИИ и будет писать его идеально.
@@TheVovaDen
Уже видно, как ИИ пишет код. Только не показывают, как этот код потом люди правят. Джунов ИИ уже может заменить, что будет дальше - никто не знает.
вооот!!! а теперь, кто будет "возникать" против ассемблера, расскажи про драйверы... Там уже без регистров и ассемблера не обойдёшься...Да и с плюсами столько "косяков" что лучше их обходить стороной.
Ссылку на asm драйвер приведите пжста!
ПС. Исходники драйверов есть в Linux.
Знать очень полезно. Писать на нём особо нет смысла. Только вставки и критические участки. На нём сейчас актуально писать под DSP, и всякие VLIW архитектуры. На этом, пожалуй, всё.
Косяки с плюсами только у тех, кто ниасилил. 😅
Я с посредственными знаниями пайтона 🪦
Знать слабо Пайтон, это по сути вообще не знать программирование, я бы ещё понял про С++
Фанаты асемблера меня всегда поражали своей упертостью. Если им нравится садомазо, я не могу их лишать этого удовольствия.
Кроме того вы вопиюще неправильно используете МК, т. к. для генерации частоты уже дцать лет есть аппаратный PWM!!!
Это не генерация шим, а демонстрация концепции разных подходов. Не кто не кого не заставляет писать на Асемблере, у каждого свой путь и свои предпочтения.
В ассемблерной версии выкинута инициализация векторов прерываний, что не есть хорошо, отсюда и такой маленький размер. Да и стёк надо бы правильно инициализировать, а не оставлять в каком попало состоянии.
В первом уроке рассказывать новичкам это будем им сложно. Можно ссылку на Ваши уроки - что бы в будущем правильно излагать материал. Спасибо.
@@AlexanderRozhkov_ К сожалению, уроков не веду. Недостаточно свободного времени. Но готов поделиться опытом в комментариях.
_стёк надо бы правильно инициализировать_ - когда-то будучи школьником, я *стек* называл как "стёк". Меня обсмеивали! :)
@@DAlexMaster По русски "стёк", по английски "stack". Оба варианта правильны. Смотря какой язык использовать.
@@Alexander_Gurov_RF
_По русски "стёк", по английски "stack_ - по-русски *стёк* имеет лишь две формы - существительное и глагол. В первом случае это означает *водосток* , а во втором случае - прошедшее время завершённого процесса стекания чего-либо. Иных смыслов данное слово не имеет! Соответственно им (словом "стёк") неправильно называть линейную списочную структуру данных, которая в английском языке имеет название *stack*
*Учим матчасть!*
программирую, но Assembler в работе вообще не нужен - C максимум
Пользоваться Ассемблером или нет выбор каждого. Все зависит от целей и конечного результата. А так же от резонности потраченных ресурсов.
хорошо, но С++ != Ардуино, память съедает именно Ардуино(её встроенные функции) а не плюсы
Вы можете не изучать Асемблер, я не настаиваю.
@@AlexanderRozhkov_ я не говорю что он не нужен, он нужен и на необходимом мне уровне я его знаю, я говорю что обвинение плюсов не оправданы, обвинять нужно ардуиновские либы
Если проект сложный то вы в своем ассемблере так напутаетесь и ошибок наплодите столько что код будет мало того как портянка здоровый да и к томуже кривее всех кривых и времени затратите на это тонну, а время это ценный ресурс
Зачастую, проект делается на си со вставками ассемблера где нужно будет быстродействие.
@@user-yp3ee2wj9x это все ещё быстрее, чем чистый ассемблер
@@user-yp3ee2wj9x в плане написания кода естественно
важно для каких целей уметь программировать на Assembler ? Ответ не был дан
Ну так это же не язык виноват, пропиши свой макрос а не ардуиновский для определения ноги да и все
Я не обвиняю язык, а показываю разницу. А как писать каждый решать сам для себя.
@@AlexanderRozhkov_ да просто как то не совсем корректно получается, в ардуино когда пишешь определение ноги под капотом срабатывает макрос, что туда прописал в определении автор так оно и подстааляется
вы совершенно не понимаете, что такое языки программирования. про с++ и с очень интересно 😂😂. а еще вы очень удивитесь, когда замените setup() на int main() и сравните занимаемую память
Циклы в разных местах расположены. Эксперимент не верен
очень сомнительная мотивировка...
У меня не было цели кого то мотивировать, а лишь показал различия. Выбирать Вам. Если Вам надо управлять включением/выключением вентилятора в зависимости от температуры - конечно на С++ быстро написали и готово. Но если у Вас система которая отвечает за быстродействие или безопасность человека - явно надо немного другой подход чем С++. Ну и наверное Вы не писали огромные программы где у Вас вся периферия занята, процессы быстродействующие и каждый байт на вес золото.
@@AlexanderRozhkov_ _наверное Вы не писали огромные программы где у Вас вся периферия занята, процессы быстродействующие и каждый байт на вес золото._
Точно... Не писал... люди которые *такое* пишут не будут смотреть видео из рубрики "урок№0.." и т.д.
Стоимость разработки программы для микроконтроллера на асике была актуальна когда микроконтроллер стоил адских денег. сейчас можно позволить себе купить ведро микроконтроллеров за такие деньги и сделать опрос каждого датчика отдельным чипом. ИМХО конечно...
@@AlexanderRozhkov_ Огромные программы, будь-то операционные системы, движки для игр/симуляторы, встраимоевое ПО для робототехники где трубуется большое быстродействие не пишится на асемблере так-то а вот на С++ сколько угодно.
@@sencis9367 _встраимоевое ПО для робототехники где трубуется большое быстродействие_
Людям которые смотрят "урок №0" до робототехники - как до луны... а до операционных систем - как до юпитера...
К чему это я...!?
К тому что обычному домашнему-"программисту" - ассемблер не нужен от слова - совсем. Под каждый камень - изучать по новой 200страниц даташита - естессно такой человек читать не будет. А скорость камней выросла так - что в принципе уже не особо важно на чем пишется ПО. Для времен камня 8080 - это было критично. А сейчас купил ESP32 - и за глаза.. хоть на бейсике пиши... завалить этот камень обычной бытовой задачей - трудно...
Впрочем не важно... все равно с ассемблером все закончится у вас "уроках" на 5 от силы...
@@user-cf7be9km5m Может и нет, иногда бывают сложные задачи в которых потребуется объединить информацию из 10ка различных туториалов, что-бы достичь результатов. Например при обработке радиосигналов на микроконтроллере иногда требуется решать задачи фактически в реальном времени, информации с камеры (визуальной однометрии) хотя конечно её лучше вынести на более мощные вычислители но микроконтроллер дешёв а объедение данных с imu частично компенсирует этот недостаток за счёт интеграции измерений от камеры в инерциальных измерениях. Но это всё именно не большие программы, просто частоты их вызова большие данных много.
смотря для каких задач. мне и си достаточно. А вот ардуины зло явное.
Каждый вправе сам выбирать свой путь.
Во первых нужно выкинут в помойку Ардуин ИДЕ ))), а потом уже вещать про Assembler ))
чем вам ардуина не угодила ?
если ее выбрасывать то давайте и HAL выкинем в армах, и LL... будем все на cmsis на си писать 🙂
не понимаю этих тупых холиваров... ардуина это просто набор библиотек взаимодействия с периферией.... и все равно как эти либы будут называться....
Все бабы богини и королевы а мужик им всем должен.
Шуруй в МД !
МД - сила，РСП - могила