Вам смешно, а у меня gcc говно генерит на ассемблерных вставках
20.03.2019, 19:28
Чего все асма так боятся - не понимаю. Небольшое количество примитивных команд, простая и понятная логика, примитивный синтаксис. Немного ебанины было со всякой интеловской сегментацией памяти, но в целом тоже все несложно.
Меня гораздо больше пугают новомодные фреймворки с охулиардом инклюдов, у всех свои глюки и ебанистический стоэтажный DOM.
Меня гораздо больше пугают новомодные фреймворки с охулиардом инклюдов, у всех свои глюки и ебанистический стоэтажный DOM.
Это не так работает. Мемы порой, никак не связаны с реальностью, но все прикидываются, словно в них верят, чтобы можно было иронически как-то это обыграть. Ассемблер - простейший язык, но в мемах он самый сложный. У ActionScript репутация тормозного, глючного и недоделанного языка, хотя HTML5 до сих пор глючнее, тормознее и недоделаннее. В Питере за год всего на 4 (четыре) солнечных дня меньше, чем в Мск, но принято его считать городом-где-всегда-дождь. И т.д. и т.п.
1. Базовых команд немного, логика простая, да. Но ведь проблема не в самом языке ассемблера, а в том, что программы на нем куда более громоздкие, с многочисленными переходами туда-сюда, локальные переменные вида rbp+8 (это больше справедливо для чтения сгенерированного кода, самому писать, особенно на masm, можно читаемо) вместо читаемого названия итп итд. Все это делает ассемблерный код более сложным для написания, чтения и модификации. И от этого никуда не деться. Ассемблерный листинг функции (даже на C) всегда длиннее.
2. А теперь я поспорю про небольшое количество примитивных команд. Если мы говорим об x86-64, то команд овер дохуя, за многими стоят километры мануалов, потому что это хитрые железо-специфичные вещи.
2. А теперь я поспорю про небольшое количество примитивных команд. Если мы говорим об x86-64, то команд овер дохуя, за многими стоят километры мануалов, потому что это хитрые железо-специфичные вещи.
+1. Ассемблер действительно берет не своей сложностью, а многословностью.
Например, взять какой-нибудь LINQ запрос из .NET array.Select(x=>x+1).OrderBy(x=>x).Last() - страшно подумать во что этот запрос развернется в ассемблере(P.S запрос носит характер примера и в нем может отсутствовать логика)
Например, взять какой-нибудь LINQ запрос из .NET array.Select(x=>x+1).OrderBy(x=>x).Last() - страшно подумать во что этот запрос развернется в ассемблере(P.S запрос носит характер примера и в нем может отсутствовать логика)
Чем выше уровень абстракции, тем больше портянка. Ассемблер LINQ (ну, я в курсе, что там сначала IL, а потом JIT) будет на километры. Да даже чтобы реализовать это на C, придется реализовать небольшое подмножество .NET Framework, ведь там классы, итераторы, коллекции, динамическое выделение памяти (про сборщик мусора вообще молчу).
Но даже код на C, который ближе некуда к железу, разворачивается в портянки. Вот пример простейшей функции и ее ассемблер. Точнее, я привел objdump объектника, потому что листинг, выдаваемый gcc просто нечитаемый из-за обилия макросов, которые он туда навтыкал.
Но даже код на C, который ближе некуда к железу, разворачивается в портянки. Вот пример простейшей функции и ее ассемблер. Точнее, я привел objdump объектника, потому что листинг, выдаваемый gcc просто нечитаемый из-за обилия макросов, которые он туда навтыкал.
Так-то да, однако, компиляторы достаточно умные и сгенерированный код достаточно шустро работает.
Писать код на чистом ассемблере- это извращение.
Другое дело- это оптимизировать небольшие участки с помощью вставок после того, как нашел проблемное место с помощью профилировщика.
Писать код на чистом ассемблере- это извращение.
Другое дело- это оптимизировать небольшие участки с помощью вставок после того, как нашел проблемное место с помощью профилировщика.
Точно. Ассемблер прост до тех пор, пока не смотреть на векторные инструкции. Встретишь так какие-нибудь vp4dpwssds, vpcmpgtb и vcvtuqq2pd (вполне реальные мнемоники) — и сразу приуныть хочется. А потом открываешь мануал (осторожно, страница реально гигантская и сильно тормозит) — и понимаешь, что лучше учиться на сварщика.
Ну так и С прост, пока тебе не надо работать с многомерными динамическими ассоциативными массивами. И то, что на перле у тебя займет одну строку, на Си легко потянет на сотню невыносимо трудочитаемого кода. А языки высокого уровня просты, пока тебе не нужен реалтайм или прямой доступ к чему-либо, там сразу же оказывается, что они это все умеют делать только очень медленно и очень хуево.
Но в C для работы с многомерными динамическими ассоциативными массивами тебе не нужно будет учить эдак под тысячу новых языковых конструкций или функций. Да и насчёт сложности я бы поспорил — хорошо написанный C-код без «божественных функций» на пару тысяч строк кода и с вменяемыми наименованиями читается куда лучше большинства векторных мнемоник асма.
Ну, я начинал вообще с машинных кодов - тяжелое детство, медленная "Микроша" и толстая книжка с инструкциями. Через месяц чтение машинного кода не представляло никакой проблемы, но очень геморройно было помнить и исправлять все относительные переходы и вызовы, если вдруг возникала потребность что-то добавить. Поэтому я перешел на ассемблер и в целом не вижу особой сложности в чтении ассемблера, тем более, что количество типовых конструкций в нем относительно невелико, пусть они и занимают много строк, но довольно быстро начинаешь читать код как бы блоками.
И это... я не понимаю этой проблемы с наименованиями - ассемблеры, как правило, позволяют оставлять комментарии, давать мнемонические названия "переменным" и подпрограммам.
И это... я не понимаю этой проблемы с наименованиями - ассемблеры, как правило, позволяют оставлять комментарии, давать мнемонические названия "переменным" и подпрограммам.
Ну, я и говорю, что ассемблер простой, пока в нём используются только типовые конструкции и наиболее распространённые инструкции. Но в настоящее время писать на ассемблере для ПК (какие-нибудь железяки, существующие в единственном экземпляре — другое дело), не используя векторных операций — абсолютно неэффективно. Поэтому практический смысл имеется только в ассемблере с SSE/AVX, а в них инструкций — сотни, и у каждой — совершенно невменяемые мнемоники. А ещё ведь скоро AVX-512 более-менее массовым станет, а в нём уже что-то около тысячи-двух инструкций (на глазок)…
А с наименованиями, на мой взгляд, две проблемы: во-первых, современный разработчик с ассемблером сталкивается в основном тогда, когда надо что-то дизассемблировать/отреверсить (в таком случае никаких комментариев, естественно, не будет), а во-вторых — размер подпрограмм: то, что на C умещается в пару десятков строк и чему можно дать краткое и ёмкое название, на ассемблере уже будет иметь длину в пару экранов, что достаточно осложняет грамотное разбиение кода на блоки.
А с наименованиями, на мой взгляд, две проблемы: во-первых, современный разработчик с ассемблером сталкивается в основном тогда, когда надо что-то дизассемблировать/отреверсить (в таком случае никаких комментариев, естественно, не будет), а во-вторых — размер подпрограмм: то, что на C умещается в пару десятков строк и чему можно дать краткое и ёмкое название, на ассемблере уже будет иметь длину в пару экранов, что достаточно осложняет грамотное разбиение кода на блоки.
1. Я могу использовать, но если надо не писать, а читать то, что сгенерировал компилятор, то ебись конем.
2. Почему Вы так упорно настаиваете именно на простоте синтаксиса и команд? Ясно-понятно, что синтаксис асма примитивный, большинство базовых инструкций предельно простые (0-1-2 операнда). Сам код сложнее. Чем более высокоуровненвый язык, тем код проще. Не надо пугать мифическими тысячами функций, если бы их использование было бы сложнее, чем писать на асме, они бы не появились. Я могу на питоне написать в одну (и не очень сложную) строку то, что на C займет сотни. А на асме еще больше.
Кроме того, даже если упарываться по асму, все равно есть сисколы, а без них - никуда.
2. Почему Вы так упорно настаиваете именно на простоте синтаксиса и команд? Ясно-понятно, что синтаксис асма примитивный, большинство базовых инструкций предельно простые (0-1-2 операнда). Сам код сложнее. Чем более высокоуровненвый язык, тем код проще. Не надо пугать мифическими тысячами функций, если бы их использование было бы сложнее, чем писать на асме, они бы не появились. Я могу на питоне написать в одну (и не очень сложную) строку то, что на C займет сотни. А на асме еще больше.
Кроме того, даже если упарываться по асму, все равно есть сисколы, а без них - никуда.
Потому что именно предельная простота синтаксиса и команд определяет простоту использования. Ассемблер - это как кирпич. Все предельно просто и понятно, можно построить здание почти любой формы. Разумеется, панельное строительство быстрее, но панелей много разновидностей, не все из них совместимы, а если нужно что-то отличное от стандартов, то все будет очень плохо. А кирпич, повторюсь, интуитивно прост и предельно понятен. Никто же не говорит, что кирпич сам по себе - это очень сложно, потому что небоскреб из него строить придется черти-сколько.
Возможно, я не понимаю, что вы вкладываете в понятие "простоты использования". В моем понимании, это реализовать то, что мне надо, быстрее и с меньшими усилиями.
Написать на C выражение для вычисления в приближенной к математической нотации чего-то проще, чем делать это в несколько шагов, раскладывать по регистрам и держать в голове, чтобы не перезатереть то, что еще нужно.
Использовать библиотечную функцию для поиска подстроки проще и быстрее, чем писать самому (и вычислительно быстрее, там векторные инструкции часто).
Использовать RAII для управления ресурсами проще и надежнее, чем делать это вручную.
Использовать LINQ для какого-то запроса проще и читаемее, чем проитерировать коллекцию вручную.
Сборщик мусора проще, чем управление памятью вручную.
Слайсы в питоне проще и читаемее, чем нагромождение библиотечных функций.
И так далее.
В среднем, при повышении уровня абстракции, писать код становится проще, меньше думаешь о реализации блоков, больше о своем коде, да и в целом уже не так многабукоф. Конечно, есть задачи, которые проще сделать на C, чем на Python.
Нам остается выбрать, на каком уровне остановиться, от машинных кодов до чего-то очень высокоуровневого, в зависимости от задачи и ряда других условий.
Написать на C выражение для вычисления в приближенной к математической нотации чего-то проще, чем делать это в несколько шагов, раскладывать по регистрам и держать в голове, чтобы не перезатереть то, что еще нужно.
Использовать библиотечную функцию для поиска подстроки проще и быстрее, чем писать самому (и вычислительно быстрее, там векторные инструкции часто).
Использовать RAII для управления ресурсами проще и надежнее, чем делать это вручную.
Использовать LINQ для какого-то запроса проще и читаемее, чем проитерировать коллекцию вручную.
Сборщик мусора проще, чем управление памятью вручную.
Слайсы в питоне проще и читаемее, чем нагромождение библиотечных функций.
И так далее.
В среднем, при повышении уровня абстракции, писать код становится проще, меньше думаешь о реализации блоков, больше о своем коде, да и в целом уже не так многабукоф. Конечно, есть задачи, которые проще сделать на C, чем на Python.
Нам остается выбрать, на каком уровне остановиться, от машинных кодов до чего-то очень высокоуровневого, в зависимости от задачи и ряда других условий.
В данном случае все началось с обсуждения мема о чудовищной сложности ассемблера для изучения и понимания. Я полагаю, что ассемблер как раз предельно прост, имеет низкий порог вхождения потому как содержит куда меньше "магических" строк, чем большинство изучаемых новичками языков, а результаты действий нагляднее. В языках высокого уровня все очень размазано по слоям абстракции, в специфическом синтаксисе черт ногу сломит, а количество магии порой запредельно. Самый печальный тому пример - Ява.
За лаконичностью языков высокого уровня часто стоят знания и высокий порог вхождения.
Вот я напишу на Перле:
print join("\n", map {"$_=$h{$_}"} sort {$h{$b} <=> $h{$a} || $a cmp $b} map {chomp; chomp; $h{$_}++; $_} <>);
Эта конструкция берет указанный в качестве входного параметра файл, читает его и выводит только уникальные строки с указанием количества их копий, отсортировав их по этому количеству в порядке убывания и по алфавиту при равном количестве. На ассемблере схожая программа будет огромной и громоздкой. На С тоже. И даже на Яве легко и просто ее сделать не получится. Но сможет ли новичок, познакомившийся с Перлом пару часов назад, прочитать код и понять, что именно он делает?
За лаконичностью языков высокого уровня часто стоят знания и высокий порог вхождения.
Вот я напишу на Перле:
print join("\n", map {"$_=$h{$_}"} sort {$h{$b} <=> $h{$a} || $a cmp $b} map {chomp; chomp; $h{$_}++; $_} <>);
Эта конструкция берет указанный в качестве входного параметра файл, читает его и выводит только уникальные строки с указанием количества их копий, отсортировав их по этому количеству в порядке убывания и по алфавиту при равном количестве. На ассемблере схожая программа будет огромной и громоздкой. На С тоже. И даже на Яве легко и просто ее сделать не получится. Но сможет ли новичок, познакомившийся с Перлом пару часов назад, прочитать код и понять, что именно он делает?
То есть вы все хотите сказать что вот прям на серъезных щах говнокодите на ассемблере ?
Да таких монстров своего дела единицы в живых нынче осталось :)
Хотя чего еще можно ожидать от лжецов и девственников.
Истинный бог из машины говорит на машинном языке (только нолики и единички, чистый абсолют для избранных, никакого лишнего дерьма, загружающего бесценные ресурсы :) )
Все что вы тут понавыкладывали это машинно-ориентированное упрощение не что иное как порождения наших затуманенных сознаний которые мы ошибочно называем "упрощениями, понятными для человека"
Да таких монстров своего дела единицы в живых нынче осталось :)
Хотя чего еще можно ожидать от лжецов и девственников.
Истинный бог из машины говорит на машинном языке (только нолики и единички, чистый абсолют для избранных, никакого лишнего дерьма, загружающего бесценные ресурсы :) )
Все что вы тут понавыкладывали это машинно-ориентированное упрощение не что иное как порождения наших затуманенных сознаний которые мы ошибочно называем "упрощениями, понятными для человека"
Я не пишу на ассемблере. И не заставите.
000011100010110000011101000011100010111000011001000101000000111000101111
0010000000001110001011110001101100001110001011100010111000010100000011100
0101111001000000000111000101110000111100000111000101111000110010000111000
1011110001101100010100000011100010111000011011000011100010111000101110000
0111000101110001000000000111000101111001011000000111000101110001011000000
1110001011100010000100010100000011100010111100011011000011100010111100101
0110001010000001110001011110001101100001110001011100001100100001110001011
1000101010000011100010111000101110000011100010111000011110000101000000111
0001011100010110100001110001011100001111000001110001011110001101000001110
0010111000011110000011100010111100100001000011100010111100101100
0010000000001110001011110001101100001110001011100010111000010100000011100
0101111001000000000111000101110000111100000111000101111000110010000111000
1011110001101100010100000011100010111000011011000011100010111000101110000
0111000101110001000000000111000101111001011000000111000101110001011000000
1110001011100010000100010100000011100010111100011011000011100010111100101
0110001010000001110001011110001101100001110001011100001100100001110001011
1000101010000011100010111000101110000011100010111000011110000101000000111
0001011100010110100001110001011100001111000001110001011110001101000001110
0010111000011110000011100010111100100001000011100010111100101100
Чтобы написать коммент, необходимо залогиниться
