Еще на тему
Деменция и фундаментализм
Популярные geek
 | it-юморРейтинг: 100,596.2 |
 | программированиеРейтинг: 17,079.0 |
 | geek pornРейтинг: 2,854.0 |
 | матанРейтинг: 2,575.4 |
 | Приколы для математиковРейтинг: 2,007.2 |
Сейчас на сайте
Всего пользователей на сайте: 1787
Меня гораздо больше пугают новомодные фреймворки с охулиардом инклюдов, у всех свои глюки и ебанистический стоэтажный DOM.
Многие языки высокого уровня до сих пор поддерживают эту красивую традицию.
Но IRL все это не надо на начальном этапе и сводится к "посмотри как сделано и повтори заклинание". И в этом плане ассемблер проще, а не сложнее.
Асм синтаксически проще, но что-либо делать на нем сложнее, потому что приходится думать на более низком уровне, это просто факт.
Что касается вопроса "зачем", то все определяется задачей. Если ты работаешь со слабеньким MCU и забивать его пару килобайт оперативки на 80% всякой сранью от С тебе кажется неприемлемым - ассемблер отлично подходит. Написание шейдеров хоть сейчас и представлено множеством вариантов, но по сути вынуждает работать с "ассемблером для видеокарт". Для реверс-инжиниринга ассемблер зачастую - единственный вариант. И т.д.
Разумеется, я не буду писать вывод на экран на ассемблере. Но я и на С его писать не буду. И на С++. И даже на Яве не буду. Это не значит, что Ассемблер, С, С++ и Ява сложнее современных интерпретаторов, это значит, что оптимизация не стоит потраченного на нее времени.
Короче, тупая аналогия. Буквы это просто, их всего 33. Но писать на русском от этого не становится легко.
2. А теперь я поспорю про небольшое количество примитивных команд. Если мы говорим об x86-64, то команд овер дохуя, за многими стоят километры мануалов, потому что это хитрые железо-специфичные вещи.
Например, взять какой-нибудь LINQ запрос из .NET array.Select(x=>x+1).OrderBy(x=>x).Last() - страшно подумать во что этот запрос развернется в ассемблере(P.S запрос носит характер примера и в нем может отсутствовать логика)
Но даже код на C, который ближе некуда к железу, разворачивается в портянки. Вот пример простейшей функции и ее ассемблер. Точнее, я привел objdump объектника, потому что листинг, выдаваемый gcc просто нечитаемый из-за обилия макросов, которые он туда навтыкал.
gcc -O0 -c c_asm_test.c
objdump -S c_asm_test.o > c_asm_test.s
Листинг, выданный gcc тут. Он напихал всяких макросов, типа .loc.
gcc -g -O0 -Wa,-adhln c_asm_test.c > c_asm_test_2.s
Писать код на чистом ассемблере- это извращение.
Другое дело- это оптимизировать небольшие участки с помощью вставок после того, как нашел проблемное место с помощью профилировщика.
И это... я не понимаю этой проблемы с наименованиями - ассемблеры, как правило, позволяют оставлять комментарии, давать мнемонические названия "переменным" и подпрограммам.
А с наименованиями, на мой взгляд, две проблемы: во-первых, современный разработчик с ассемблером сталкивается в основном тогда, когда надо что-то дизассемблировать/отреверсить (в таком случае никаких комментариев, естественно, не будет), а во-вторых — размер подпрограмм: то, что на C умещается в пару десятков строк и чему можно дать краткое и ёмкое название, на ассемблере уже будет иметь длину в пару экранов, что достаточно осложняет грамотное разбиение кода на блоки.
2. Базовых команд, покрывающих 99% случаев - несколько десятков. Один список базовых функций в каком-нибудь C легко потянет на полтысячи.
2. Почему Вы так упорно настаиваете именно на простоте синтаксиса и команд? Ясно-понятно, что синтаксис асма примитивный, большинство базовых инструкций предельно простые (0-1-2 операнда). Сам код сложнее. Чем более высокоуровненвый язык, тем код проще. Не надо пугать мифическими тысячами функций, если бы их использование было бы сложнее, чем писать на асме, они бы не появились. Я могу на питоне написать в одну (и не очень сложную) строку то, что на C займет сотни. А на асме еще больше.
Кроме того, даже если упарываться по асму, все равно есть сисколы, а без них - никуда.
Написать на C выражение для вычисления в приближенной к математической нотации чего-то проще, чем делать это в несколько шагов, раскладывать по регистрам и держать в голове, чтобы не перезатереть то, что еще нужно.
Использовать библиотечную функцию для поиска подстроки проще и быстрее, чем писать самому (и вычислительно быстрее, там векторные инструкции часто).
Использовать RAII для управления ресурсами проще и надежнее, чем делать это вручную.
Использовать LINQ для какого-то запроса проще и читаемее, чем проитерировать коллекцию вручную.
Сборщик мусора проще, чем управление памятью вручную.
Слайсы в питоне проще и читаемее, чем нагромождение библиотечных функций.
И так далее.
В среднем, при повышении уровня абстракции, писать код становится проще, меньше думаешь о реализации блоков, больше о своем коде, да и в целом уже не так многабукоф. Конечно, есть задачи, которые проще сделать на C, чем на Python.
Нам остается выбрать, на каком уровне остановиться, от машинных кодов до чего-то очень высокоуровневого, в зависимости от задачи и ряда других условий.
За лаконичностью языков высокого уровня часто стоят знания и высокий порог вхождения.
Вот я напишу на Перле:
print join("\n", map {"$_=$h{$_}"} sort {$h{$b} <=> $h{$a} || $a cmp $b} map {chomp; chomp; $h{$_}++; $_} <>);
Эта конструкция берет указанный в качестве входного параметра файл, читает его и выводит только уникальные строки с указанием количества их копий, отсортировав их по этому количеству в порядке убывания и по алфавиту при равном количестве. На ассемблере схожая программа будет огромной и громоздкой. На С тоже. И даже на Яве легко и просто ее сделать не получится. Но сможет ли новичок, познакомившийся с Перлом пару часов назад, прочитать код и понять, что именно он делает?
— Она тебя сожрет!
пожирающий неокрепшие мозги молодых, неискушенных и оч амбициозных программеров
Да таких монстров своего дела единицы в живых нынче осталось :)
Хотя чего еще можно ожидать от лжецов и девственников.
Истинный бог из машины говорит на машинном языке (только нолики и единички, чистый абсолют для избранных, никакого лишнего дерьма, загружающего бесценные ресурсы :) )
Все что вы тут понавыкладывали это машинно-ориентированное упрощение не что иное как порождения наших затуманенных сознаний которые мы ошибочно называем "упрощениями, понятными для человека"
а тогда те кто разрабатывают процессоры кто? это же уровень ниже даже машинных кодов и даже понятия 0 и 1 ибо там аналоговые и филосовские величины есть типа Z
Относительно популяции их реально единицы.
0010000000001110001011110001101100001110001011100010111000010100000011100
0101111001000000000111000101110000111100000111000101111000110010000111000
1011110001101100010100000011100010111000011011000011100010111000101110000
0111000101110001000000000111000101111001011000000111000101110001011000000
1110001011100010000100010100000011100010111100011011000011100010111100101
0110001010000001110001011110001101100001110001011100001100100001110001011
1000101010000011100010111000101110000011100010111000011110000101000000111
0001011100010110100001110001011100001111000001110001011110001101000001110
0010111000011110000011100010111100100001000011100010111100101100