Почему программы не пишутся в блоке чаще? [закрытый]

Мне нравится программировать на языке ассемблера, но требуется больше кода, чтобы делать то же самое, что и на языке высокого уровня, и существует прямая корреляция между строки кода и ошибок. (Это было объяснено несколько десятилетий назад в Мифический человеко-месяц .)

Можно думать о C как о «высокоуровневой сборке», но сделайте несколько шагов выше, и вы окажетесь в другом Мир. В C # вы не будете дважды задумываться, чтобы написать это:

foreach (string s in listOfStrings) { /* do stuff */ }

Это были бы десятки, может быть, сотни строк кода на ассемблере, каждый программист, реализующий его, использовал бы другой подход, и следующий человек, который придет, должен был бы это понять. из.Поэтому, если вы верите (как и многие), что программы написаны в первую очередь для чтения другими людьми, сборка будет менее читабельной, чем типичный HLL.

Редактировать: Я накопил личную библиотеку кода, используемого для общих задач, и макросов для реализации структур управления, подобных Си. Но я ударился о стену в 90-х, когда графические интерфейсы стали нормой. Слишком много времени тратилось на рутинные дела.

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

Что ж, я писал много ассемблера «в былые времена», и могу заверить вас, что я намного продуктивнее, когда пишу программы на язык высокого уровня.

I Я изучаю сборку в comp org прямо сейчас, и, хотя это интересно, также очень неэффективно писать. Вы должны держать в голове гораздо больше деталей, чтобы все работало, а также медленнее писать те же самые вещи. Например, простой цикл из 6 строк в C ++ может равняться 18 или более строкам сборки.

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

То, что C имеет над хорошим ассемблером макросов, - это язык C. Проверка типов. Конструкции петель. Автоматическое управление стеком. (Почти) автоматическое управление переменными. Методы динамической памяти в ассемблере - огромная боль в заднице. Правильное выполнение связанного списка просто страшно по сравнению с C или еще лучше list foo.insert (). И отладка - ну, нет никакого спора о том, что легче отлаживать. Здесь HLL выигрывают.

Я написал код ассемблера почти половину своей карьеры, что позволяет мне легко мыслить ассемблером. это помогает мне увидеть, что делает компилятор C, что снова помогает мне писать код, который компилятор C может эффективно обрабатывать. Хорошо продуманная процедура, написанная на C, может быть написана для вывода именно того, что вы хотите на ассемблере, с небольшой работой - и это портативно! Мне уже пришлось переписать несколько старых asm-подпрограмм обратно на C по причинам кроссплатформенности, и это неинтересно.

Нет, я буду придерживаться C и буду иметь дело с периодическим небольшим снижением производительности по сравнению с потерей производительности, которую я получаю с помощью HLL.

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

Появляются технологии, которые делают вещи проще и доступнее.

РЕДАКТИРОВАТЬ - чтобы перестать обижать людей, я удалил некоторые слова.

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

Тем не менее, я думаю, что есть еще допустимые варианты использования сборки. Например, у меня есть несколько довольно оптимизированных процедур сборки для обработки больших объемов данных, использующих SIMD и следуя параноидальному подходу «каждый бит священен» [цитата В. Стоба]. (Но учтите, что наивные реализации ассемблера часто намного хуже, чем то, что компилятор мог бы сгенерировать для вас.)

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

Итак, вы в основном говорите, что с умелым использованием сложного ассемблера вы можете сделать свой код ASM все ближе и ближе к C (или, в любом случае, к другому низкоуровневому языку вашего собственного изобретения), пока в конечном итоге вы так же продуктивны, как программист на C.

Это ответ на ваш вопрос? ; -)

Я не говорю это праздно: я программировал, используя именно такой ассемблер и систему. Более того, ассемблер мог нацеливаться на виртуальный процессор, а отдельный транслятор компилировал вывод ассемблера для целевой платформы. Примерно так же, как и с IF от LLVM, но в его ранних формах, предшествующих ему примерно на 10 лет. Таким образом, была переносимость плюс возможность писать процедуры для конкретного целевого ассемблера, где это требовалось для повышения эффективности.

Написание с использованием этого ассемблера было примерно таким же продуктивным, как и C, и по сравнению с GCC-3 (который был примерно в то время, когда я был задействован) ассемблер / переводчик создавал код, который был примерно таким же быстрым и обычно меньшего размера. Размер был действительно важен, и в компании было мало программистов, и они были готовы обучать новых сотрудников новому языку, прежде чем они смогут сделать что-нибудь полезное. И у нас было резервное копирование, чтобы люди, не знающие ассемблера (например, клиенты), могли написать C и скомпилировать его для того же виртуального процессора, используя то же соглашение о вызовах и так далее, чтобы он имел аккуратный интерфейс.Так что это было похоже на незначительную победу.

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

Подводя итог: возможно, вам не нравится C, но это не значит, что усилия по использованию C больше, чем усилия по созданию чего-то лучшего.

Потому что так всегда: время идет, и хорошее тоже проходит: (

Но когда вы пишете asm-код, это совершенно другое ощущение, чем когда вы кодируйте высокоуровневые языки, хотя вы знаете, что это гораздо менее продуктивно. Это как художник: вы можете рисовать все, что вам нравится, как вам нравится, без каких-либо ограничений (ну, только функциями процессора) ... Вот почему я люблю его. Жаль, что этот язык ушел. Но пока кто-то еще его помнит и закодирует, он никогда не умрет!

Одно из первых открытий (вы найдете его в Мифическом человеко-месяце Брукса), которое взято из опыт 1960-х годов) заключался в том, что люди более или менее продуктивно работали на одном языке, чем на другом, в отлаженных строках кода в день. Это, очевидно, не всегда верно и может сломаться, если зайти слишком далеко, но в целом это было верно для языков высокого уровня времен Брукса.

Таким образом, самый быстрый способ повысить продуктивность - это использовать языки, в которых одна отдельная строка кода делает больше, и это действительно работает, по крайней мере, для таких сложных языков, как FORTRAN и COBOL, или, чтобы привести более современный пример C.

Как разработчик, проводящий большую часть своего времени в мире встроенного программирования, я бы сказал, что сборка - это еще не мертва. / устаревший язык. Существует определенный уровень кодирования, близкий к металлическому (например, в драйверах), который иногда не может быть выражен так точно или эффективно на языке более высокого уровня. Мы пишем почти все наши процедуры аппаратного интерфейса на ассемблере.

При этом этот ассемблерный код обернут так, что его можно вызывать из кода C, и он рассматривается как библиотека. Мы не пишем всю программу на ассемблере по многим причинам. Прежде всего, это портативность; наша кодовая база используется в нескольких продуктах, использующих разные архитектуры, и мы хотим максимизировать объем кода, который может совместно использоваться ими. Во-вторых, знакомство разработчиков. Проще говоря, в школах не преподают сборку, как раньше, и наши разработчики намного продуктивнее работают на C, чем на сборке. Кроме того, у нас есть широкий спектр дополнительных функций (таких как библиотеки, отладчики, инструменты статического анализа и т. Д.), Доступных для нашего кода C, которые недоступны для кода на языке ассемблера. Даже если бы мы захотели написать программу на чистом ассемблере, мы не смогли бы этого сделать, потому что несколько критически важных аппаратных библиотек доступны только в виде C-библиотек. В каком-то смысле это проблема курицы и яйца.Людей отталкивают от сборки, потому что для нее не так много библиотек и инструментов разработки / отладки, но библиотеки / инструменты не существуют, потому что недостаточно людей используют сборку, чтобы гарантировать усилия по их созданию.

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

Если средняя производственная программа содержит, скажем, 100 тыс. Строк кода, и каждая строка содержит примерно 8-12 инструкций ассемблера, это будет 1 миллион инструкций ассемблера.

Даже если бы вы могли написать все это вручную с приличной скоростью (помните, что вам нужно написать в 8 раз больше кода), что произойдет, если вы захотите изменить некоторые функции? Понимание того, что вы написали несколько недель назад из этого миллиона инструкций, - это кошмар! Нет модулей, классов, объектно-ориентированного дизайна, фреймворков, ничего. И количество похожего кода, которое вам нужно написать даже для самых простых вещей, в лучшем случае устрашает.

Кроме того, вы не можете оптимизировать свой код почти так же хорошо, как язык высокого уровня. Если C, например, выполняет безумное количество оптимизаций, потому что вы описываете свое намерение, а не только свой код, на ассемблере вы пишете только код, ассемблер действительно не может выполнить какие-либо заметные оптимизации вашего кода. То, что вы пишете, - это то, что вы получаете, и поверьте мне, вы не можете надежно оптимизировать 1 миллион инструкций, которые вы исправляете и исправляете по мере написания.

Черт, я компилятор.

Я только что просмотрел тысячи строк кода, пока вы читали это предложение. Я просмотрел миллионы возможностей оптимизации одной вашей строки с помощью сотен различных методов оптимизации, основанных на огромном количестве академических исследований, на изучение которых вы бы потратили годы. Я не почувствую никакого смущения, даже легкого раздражения, когда я конвертирую трехстрочный цикл в тысячи инструкций, чтобы сделать его быстрее. Мне не стыдно пойти на оптимизацию или проделать самые грязные трюки. И если ты не хочешь, чтобы я это делал, может быть, на день или два, я буду вести себя так, как ты хочешь. Я могу трансформировать методы, которые использую, когда захотите, даже не меняя ни одной строчки вашего кода. Я даже могу показать вам, как ваш код будет выглядеть в сборке, на разных архитектурах процессоров и разных операционных системах и в разных соглашениях о сборке, если хотите. Да, все за секунды. Потому что, знаете, я могу; и вы знаете, вы не можете.

P.S. О, кстати, вы не использовали половину написанного кода. Я сделал тебе одолжение и выбросил его.

В дополнение к ответам других людей о удобочитаемости, удобстве сопровождения, более коротком коде и, следовательно, меньшем количестве ошибок, а также о том, что он намного проще, я добавлю дополнительную причину:

скорость программы.

Да, в ассемблере вы можете вручную настроить свой код, чтобы использовать каждый последний цикл и сделать его настолько быстрым, насколько это физически возможно. Однако у кого есть время? Если вы напишете не совсем глупую программу на языке C, компилятор сделает действительно хорошую работу по оптимизации за вас. Вероятно, вы сделаете не менее 95% оптимизаций вручную, не беспокоясь о том, чтобы отслеживать какие-либо из них. Здесь определенно существует правило 90/10, согласно которому последние 5% оптимизации займут 95% вашего времени. Так зачем беспокоиться?

$$$

Компания нанимает разработчика, чтобы он помог превратить код в $$$. Чем быстрее будет создан полезный код, тем быстрее компания сможет превратить этот код в $$$.

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

Переносимость всегда проблема - если не сейчас, то по крайней мере в конце концов. Индустрия программирования ежегодно тратит миллиарды на перенос старого программного обеспечения, которое на момент написания «очевидно» не имело никаких проблем с переносимостью.

Преимущество HLL еще больше, когда вы сравниваете ассемблер с языком более высокого уровня, чем C, например Java, Python или Ruby. Например, в этих языках есть сборка мусора: не нужно беспокоиться о том, когда освободить кусок памяти, и нет утечек памяти или ошибок из-за слишком раннего освобождения.

Сборка не может переноситься между разными микропроцессорами.

Я написал пакеты ассемблера для микросхем 6502, Z80, 6809 и 8086. Я прекратил это делать, как только компиляторы C стали доступны для платформ, к которым я обращался, и сразу стал как минимум в 10 раз производительнее. Большинство хороших программистов используют инструменты по рациональным причинам.

Я уверен, что есть много причин, но я могу вспомнить две быстрые причины:

1. Ассемблерный код определенно сложнее читать (я уверен, что его написание также требует больше времени)
2. Когда у вас есть огромная команда разработчиков, работающих над продуктом, полезно, чтобы ваш код был разделен на логические блоки и защищен интерфейсами.

Листая эти ответы, Готов поспорить, 9/10 респондентов никогда не работали со сборкой.

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

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

Однако, что касается фактического написания большого количества кода на ассемблере, есть несколько причин, по которым это сделано не так много.

• В этом просто нет (почти) необходимости. За исключением чего-то вроде очень ранней инициализации системы и, возможно, нескольких фрагментов ассемблера, скрытых в функциях или макросах C, весь очень низкоуровневый код, который когда-то мог быть написан на ассемблере, можно без труда написать на C или C ++.

• Код на языках более высокого уровня (даже C и C ++) концентрирует функциональность в гораздо меньшем количестве строк, и есть значительные исследования, показывающие, что количество ошибок коррелирует с количеством строк исходного кода. Т.е. та же проблема, решаемая на ассемблере и C, будет содержать больше ошибок в ассемблере просто потому, что он длиннее. Тот же аргумент мотивирует переход на языки более высокого уровня, такие как Perl, Python и т. Д.

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

По сути, все вышеперечисленное связано с уровнем абстракции, доступным вам в ассемблере по сравнению с C или каким-либо другим языком. Ассемблер вынуждает вас создавать все свои собственные абстракции и поддерживать их с помощью собственной самодисциплины, когда любой язык среднего уровня, такой как C, и особенно языки более высокого уровня, предоставляют вам абстракции из коробки, а также способность относительно легко создавать новые.

Как уже упоминалось ранее, причина существования любого инструмента в том, насколько эффективно он может работать. Поскольку HLL могут выполнять те же задачи, что и многие строки кода asm, я думаю, что для ассемблера естественно заменять другие языки. А для того, чтобы возиться с аппаратным обеспечением - есть встроенная сборка на C и другие варианты в соответствии с языком. Доктор Пол Картер на языке PC Assembly Language

говорит: "... лучшее понимание того, как компьютеры действительно работают на более низком уровне , чем в языки программирования, такие как Паскаль. Обретя более глубокое понимание того, как работают компьютеры, читатель может гораздо более разрабатывать программное обеспечение в {{1} } языки более высокого уровня, такие как C и C ++. Обучение программированию на языке ассемблера - отличный способ достичь этой цели ».

У нас есть введение в сборка в моих курсах колледжа. Это поможет прояснить концепции. Однако я сомневаюсь, что кто-то из нас напишет 90% кода на ассемблере. Насколько актуальны глубокие знания сборки сегодня?

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

Итак, сейчас, реально, может быть очень сложно принять правильное решение, скажем, о том, какие регистры вам следует использовать или какие инструкции немного более эффективны. Компиляторы могут использовать эвристику, чтобы выяснить, какие компромиссы, вероятно, принесут наилучший результат. Мы, вероятно, сможем продумать более мелкие проблемы и найти локальные оптимизации, которые могут превзойти наши теперь довольно сложные компиляторы, но есть вероятность, что в среднем случае хороший компилятор с первой попытки сделает работу лучше, чем, вероятно, хороший программист.В конце концов, как Джон Генри, мы могли бы победить машину, но мы могли бы серьезно сгореть, добираясь туда.

Наши проблемы теперь тоже совсем другие. В 1986 году я пытался придумать, как получить немного больше скорости от небольших программ, которые требовали размещения на экране нескольких сотен пикселей; Я хотел, чтобы анимация была менее резкой. Хороший случай для ассемблера. Теперь я пытаюсь понять, как представить абстракции вокруг языка контракта и политики сервисного обслуживания для ипотечных кредитов, и я бы предпочел прочитать что-то, что похоже на язык, на котором говорят люди из бизнеса. В отличие от макросов LISP, макросы сборки не требуют особого соблюдения правил, поэтому даже если вы сможете получить что-то достаточно близкое к DSL в хорошем ассемблере, он будет подвержен всевозможным причудам, которые выиграли ''. Если я написал один и тот же код на Ruby, Boo, Lisp, C # или даже F #, у меня возникнут проблемы.

Если ваши проблемы легко выразить на эффективном языке ассемблера, тем не менее, больше возможностей для вас.

C - это макроассемблер! И самый лучший!

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

А абстракции более высокого уровня и переносимость делают для большинства людей более целесообразным писать системное программное обеспечение на C. И хотя вам может и не понадобиться переносимость сейчас, если вы потратите много времени и денег на написание какой-то программы, которую вы, возможно, не захотите чтобы ограничить себя в том, для чего вы сможете использовать его в будущем.

То же самое, что и другие.

В старые добрые времена до изобретения C, когда единственными языками высокого уровня были такие, как COBOL и FORTRAN, было много вещей, которые просто невозможно было сделать без использования ассемблера. Это был единственный способ получить полную гибкость, получить доступ ко всем устройствам и т. Д. Но затем был изобретен C, и почти все, что было возможно в сборке, стало возможным в C. С тех пор я написал очень мало сборки. тогда.

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

Я полагаю, что ASM даже на x86 (_64) имеет смысл в тех случаях, когда вы многое выиграете, используя инструкции, которые компилятору сложно оптимизировать для . x264, например, использует много asm для своего кодирования, и выигрыш в скорости огромен.