Стоит ли изучать диалект assembly?

Я действительно удивлен, увидев так много "no" ответов на этот вопрос. Я думаю, вам следует выучить assembly.

Я не ожидаю, что вы когда-нибудь будете использовать assembly непосредственно в своей работе. Но из этого не следует, что вы не должны этому учиться.

Изучение assembly научит вас тому, что происходит внутри компьютера. Это поможет вам понять, что на самом деле делает программное обеспечение.

Дело действительно в профессионализме. Вы собираетесь стать профессиональным инженером-программистом? Или ты собираешься стать хакером copy-and-paste? Конечно, последний может оплачивать счета, но быть профессионалом гораздо приятнее.

Услышать, как кто-то говорит: "Nah, don't bother learning assembly," звучит для моих ушей так: "вот поваренная книга для строительства мостов. Вам не нужно изучать физику или технику, чтобы построить мост. Просто следуйте этим рецептам.- Нет, благодарю вас.

Добрый день,

Я выучил PDP ассемблер, когда делал свой выбор. Анг. последний диалект ассемблера, который я действительно использовал, имел четыре различных режима адресации памяти. Последний диалект, на котором я учился, имел 17 режимов!

Не уверен, что изучение ассемблера действительно дает вам сегодня. Тогда это была существенная часть потока CS в моем избраннике. анг. степень.

Что касается изучения C++, я бы просто сел и работал через " ускоренный C++" , который подходит к C++ сам по себе, а не как "C with other bits".

Что касается C, я бы просто работал с последней версией "C Programming Lanuage" (a.k.a.) К'н'R

Надеюсь, это поможет.

овации, Грабить

Теперь, если бы вы спросили о нанопрогрессировании... (-:

"Is it worth it to learn a dialect of assembly?"

Я запрограммировал assembly профессионально. М68к работает с факсом и сканером. Также windows VxDs (драйверы виртуальных устройств) вернулись в windows 3/3.1 дней до того, как у них появился реальный kernel.

Когда вы кодируете assembly для выполнения обычных программных задач (копирование памяти, объединение строк, вызов обработчиков прерываний и т. д.), Это довольно интересно. Иногда вы кодируете assembly, чтобы быть вызванным кодом C, чтобы выполнить какую-то специализированную задачу как можно быстрее на данном процессоре. Это может быть более интересно, потому что вы ищете способы воспользоваться каждым циклом, который дает вам процессор. Вы заботитесь о том, что находится в кэше L1 процессора. Вы заботитесь о выравнивании данных в памяти, чтобы избежать попадания cacheline (если я помню этот термин). Вы заботитесь о двухпроводной процессорной архитектуре и используете правильные 2 или 3 или 4 инструкции в правильном порядке, так что 2 или 3 или 4 вещи происходят с одним тиком часов (-один из тех HZ в XgHz процессора).

Когда вы кодируете assembly для управления пользовательским оборудованием, теперь вы делаете такие вещи, как заполнение 16-байтного буфера памяти, настройка операции DMA и передача этих данных контроллеру, который делает что-то вроде управления барабаном лазерного принтера. А барабан вращается и не может быть остановлен, и хочет, чтобы его следующие 16 байт в течение следующих 5us. Конечно, это можно сделать в C или C++. Но примеров можно привести бесконечное множество.

Я бы, может быть, обрезал последнюю половину вашего вопроса "Is it worth it to learn a dialect of assembly?" и сделал его "Is it worth it to learn?"

Если вы любите Программирование, то то, как вы определяете "worth", включает в себя некоторый компонент любви к программированию. В этом смысле я никогда не учился чему-то в программировании и не думал, что оно того стоит. Даже если я не использовал его много послесловий.

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

Но все это пушистое дерьмо в сторону, я считаю, что оно стоит того, чтобы по крайней мере получить-некоторый - фон assembly. Идите вперед и выясните, как написать assembly, чтобы заменить несколько простых процедур stdlib, таких как strcpy, memmove и т. д. Затем попытайтесь оптимизировать их, вызывая их из C миллион раз, при этом синхронизируя его.

Я бы не стал учиться ASM. Если вы хотите узнать C/C++, то начните с этого. По мере того как качество вашего кода будет расти, вы можете обнаружить, что у вас есть потребность в ASM. 99% в большинстве случаев вы этого не сделаете, но время от времени вам это может понадобиться.

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

Я так и сделал, и думаю, что это помогло мне в то время. Это больше не помогает мне изо дня в день, но я думаю, что это будет зависеть от вашей работы.

Я изучал ассемблер 20 лет назад на Commodore и снова в университете на мейнфрейме IBM. Я не могу сказать, что это помогает мне в моей нынешней работе.

Это, вероятно, не будет иметь большой пользы, если у вас нет прямого применения для этого. Если вы хотите получить общие знания, то C/C++-прекрасное место для начала.

Тем не менее, проблемы, которые ставит assembly, очень интересны, и для их решения требуется совершенно другой образ мышления.

Я потратил немного времени на изучение Z80 assembly, программируя калькулятор TI-86. Набор инструкций Z80 довольно мал, и новизна программирования калькулятора в assembly очень забавна.

ticalc.org имеет много хороших ресурсов по программированию TI assembly .

Я согласен с Марком. Я думаю, что это похоже на изучение MSIL, когда пишешь на C#, VB.NET или другом .NET языке. Это помогает узнать, что происходит под капотом, но вы можете всю свою жизнь создавать приложения, которые работают и никогда в этом не нуждаются.

№ Если вы не хотите для удовольствия, вам действительно не нужно учиться assembly.

Есть некоторые вещи, которые вам нужно знать assembly для создания драйверов, OS разработки, разработки эксплойтов, но помимо этого, я лично считаю, что вы можете довольно счастливо кодировать вечно, не зная этого.

Если вам действительно нужно выучить assembly, вы это узнаете - я бы не стал учить его ради того, чтобы выучить его..

Если вы пишете неуправляемый C++, иногда очень важно знать хотя бы основные x86 assembly, двоичные системы счисления и т. д. Я в основном занимаюсь разработкой C/C++, и мне иногда нужно отлаживать производственный код для ошибок, которые настолько специфичны для представления машинного кода, созданного компилятором, что единственный способ найти, а затем исправить ошибку-прочитать декомпилированный assembly и выяснить, почему компилятор создал его как таковой.

Для получения дополнительной информации о assembly см. вопрос: как лучше всего узнать Assembly? В частности, для тех, кто имеет опыт работы с динамическими языками .

Assembly - это не очень сложно. Как только вы познакомитесь с C, потратьте день или два на изучение базового assembly. Его полезность с точки зрения отладки огромна, плюс его удовольствие от возможности писать код, который превосходит эквивалент C по скорости в 10, 15 или более раз.

Я бы не советовал учить "modern assembler language".

Однако зная немного о ассемблере MOS 6510 и просматривая разобранные C64 Kernel, a.k.a. это OS и базовый интерпретатор, который очень помог мне понять, что происходит внутри компьютера - такие вещи, как прерывания и страницы памяти.

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