Ассемблер - ад програмиста или всё-таки рай для него же?
Нуссс. Начну из далека. На заре вычислительной техники народ довольствовался механическими вычислительными машинками. Не буду на них останавливаться - это тема для длинющего поста, начиная с камешков на берегу и заканчивая машинкой "Энигма".
Потом, почти одновременно, появились аналоговые вычислительные машины - АВМ. Они имели крайне узкую направленность, и грубо говоря пытались электронными, а зачастую и физическими методами повторить некий физ. процесс и получить результат/расчёт того или иного физ. процесса. Головоломка уже не для программистов, а для физиков и математеков.

Про квантовые компы я промолчу тихи в тряпочку - сколько ни читал - муть мутная и мне непонятная. Стар я видать стал, а может стал и СуперСтар...
Говорить я буду о привычных компах - которые работают с единичками и ноликами (троичные погибли, хотя в СССР были нехилые наработки). Вроде всё норм, но комп, процессор, понимает как раз енти нули и единички. Ещё на этапе проектирования железяки народ понял енту проблему и начал объединять их в группы, кратные степени двойки. Так появился байт (2^3 = 8), а потом и слово (2^4 = 16). И тут же различные производители железа придумали первый геморрой для программистов - порядок следования байт в слове. Little-Endian и Big-Endial - эти слова знакомы каждому сетевику и привычно вызывают когнитивный диссонанс...
Но ладно, вернёмся к ассемблеру. На заре программирования под цифровые процессора народ вбивал программу тумблерами - битик за битиком. Производительность труда была на наименьшейшем уровне, а вероятность щёлкнуть не тот битик самой большой.
Нервы не выдержали и мисс Кэтлин Бут решила облегчить себе работу, создав первый в мире ассемблер для ARC2 (военный авиационный вычислитель).
Эту идею подхватили остальные. Что самое интересное - на языке Ассемблера можно добиваться максимальной производительности (самая популярная библиотека ffmpeg имеет множество ассемблерного кода под разные архитектуры) - выжать из процессора все соки. Такое же происходит в различных математических библиотеках.
Вроде всё с ассемблером хорошо, кроме одного - там команды процессору заменены на мнемокоды - краткие символьные представления команды процессора. Писать программу стало удобно, понятно. Появились кросс-ассемблеры (низкий уровень llvm)
Но оснавная засада осталась - трудоёмкость программирования и половина башки программиста занята архитектурой компа (да-да, там не только про проц надо помнить, но и про периферию).

А что итого? Я понимаю, что питонисты нифига не поймут - они даже не понимают, что каждая питон-либа это просто обёртка под высокоэффективным кодом на Си. Ассемблер жив и будет жив, те же "тысяча строк" ассемблера под линуксом - это и есть основа ядра ОС. Потом уже можно писать на Си, Си++, даже Расте (чёт ОС растоманов зачахла - видать пришло понимание, что язык высокого уровня не может использоваться наравне с Ассемблером или СИ).
Язык Ассемблера, как продился, так и будет жив. Есть яыки программирования близкие к АСМу - тот же Си, или Форт, но никто не даст программисту той мощи и контроля за компом как АСМ. Тот же Си в своих диалектах везде имеет возможность АСМ-вставок.
Что же до программирования на АСМе - мне он нравится, но... Всегда надо иметь баланс в голове. Поверьте strncpy() из Си будет более оптимизирована чем ваша реализаций на АСМе, а вот к-либо формула, вычисляющая интеграл, которого нет в clib - лучше уже на асме, особенно если оно вычисляется в цикле..
Комментарии