Тут я отвечу на вопрос "Зачем нормальный программист должен знать ассемблер?" но сначала пятиминутка ненависти
Ну собственно, есть такая тема, что люди, которые не то что ассемблера, даже сишку толком не пробовавшие, пишут на своих жабоскриптах такую дикую хуиту с точки зрения оптимизации, что просто пиздец. Ибо нет нифига понимания(даже примерного) в какие такие машинные инструкции будет оттранслирована та хуерга, которую наплодили эти "программисты".
Раньше мой дед на целероне 400 мгц 256 метрами ОЗУ успешно смотрел интернет на несвежем дистрибутиви GNU/Linux. Но потом тупые индусы понаделали тормозных жабаскриптов и дед начал жаловаться на появление какого-то непонятного окошка "скрипт недоступен". Он еще начал интересоваться, что такое скрипт и на что он должен отвечать. Ну типа типичные последствия. Вообще, дофига сайтов адово тормозят от этих говен, поэтому у меня NoScript всегда наготове, ибо от этого говна тормозятся даже современные браузеры на современном железе. Это ж надо было дойти до того, чтобы делать абгрейд из-за того, что какие-то *** понаписали быдлокода на JS? Если вы у себя на сервер-сайде ворочаете всякие тормозные питоны, похопе и Node.js то это ваши личные половые проблемы. Но вот когда вы кормите этим JS-говном МОЙ процессор, тут уж я на это вынужден применять меры, вроде NoScript
http://www.opennet.ru/opennews/art.shtml?num=36962 вот на такое клиенд-сайд веб программирование (если его сильно запаковать в сандбокс) я согласен. Есть еще такая тема, как asm.js http://habrahabr.ru/post/171561/ но это всё полумеры.
А теперь по теме, нафига вообще ASM. Любой (за исключением CUDA и прочей GPU-ускоренной хреноты) код на любом ЯП в итоге транслитуется в опкоды и переваривается центральным процессором (всякие CUDA и опенжл передаются в видеокарту и перевариваются через GPU). Я лично не против, чтобы кто-нибудь писал на языках, подобных Java, JavaScript, Python, Ruby и что там еще... Вся беда в том, что для эффективного программирования даже на таких ВЫСОКОУРОВНЕВЫХ ЯП как эти, необходимо хотя бы примерно представлять, в какой машинный код преобразуются ваши высокоуровневые конструкции.
Иногда приходится смотреть на сгенерированный сишным компилятором код, чтобы понять причины тормозов. Чтение ассемблерного выхлопа GCC позволило мне выявить хреновую оптимизацию записывания байтиков в стек, вот http://gcc.1065356.n5.nabble.com/Ways-to-fill-the-stack-td912561.html почитайте (да, я знаю, у меня плохой английский)
Понимание архитектуры ЭВМ, недостатков некоторых вещей (типа NULL-terminated string http://www.joelonsoftware.com/articles/fog0000000319.html ) позволяет избегать ошибок на более высоких уровнях.
Меня тут обвиняли что я статейки какие-то даю, так вот тут я их действительно выдам
http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html
https://lwn.net/Articles/250967/
http://www.insidepro.com/kk/145/145r.shtml
https://savannah.nongnu.org/projects/pgubook/
И вот типа цитата, но я не вполне согласен с ней. Иногда ASM нужен именно для написания
Целью обучения программированию на асме, как ни странно, не может быть само по себе программирование на асме, это навык (если его рассматривать с профессионально-коммерческой точки зрения) абсолютно бессмысленный. Никто никогда не пишет на асме. Но при этом опыт такого писания жизненно необходим, чтобы примерно представлять себе, что на самом деле происходит при выполнении программы. И с этой колокольни, вообще говоря, пофигу, какой ассемблер и под какой процессор изучать. Ну, допустим, процессор всё-таки желательно использовать живой и реально существующий, чтобы не оставалось ощущения, что «с настоящим точно не получится», но и только.
Критика приветствуется
