Ассамблея по-прежнему актуальна? [закрыто]

Существуют ли серьезные различия между языком ассемблера и языками более высокого уровня, когда речь идет о кодировании и / или управлении проектами? Очевидно, что для выполнения конкретной операции требуется больше операторов на языке ассемблера, чем в большинстве других языков, но есть ли различия, которые влияют на то, как проект должен (или должен) выполняться на основе ориентации на язык ассемблера (в частности, язык ассемблера x86 / x64) ?

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

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

Да - но не часто

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

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

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

Но вещи начали меняться в середине 1990-х годов. Процессоры начали включать такие функции, как конвейерная обработка и прогнозирование ветвлений, поэтому наиболее эффективный порядок команд не всегда был очевиден для человека. Хуже того, наиболее эффективный порядок варьировался между процессорами в одном семействе; например, компиляторы PowerPC обычно предлагали целевые коммутаторы для серий G3, G4 и G5. Один и тот же объектный код будет работать на всех из них, но он будет работать на одном из этих рядов более эффективно.

С тех пор упорядочивание инструкций становится все более сложным, особенно на более архитектурно сложных процессорах, таких как x86, PowerPC и SPARC. (Я считаю, что ARM все еще довольно прост в этом смысле.) Большим дополнительным фактором является размер кода - код, который использует больше циклов ЦП, но может оставаться в кэше ЦП, часто будет работать намного быстрее, чем код, который использует меньше циклов ЦП, но вызывает медленные выборки памяти , Основные современные компиляторы могут гораздо лучше оптимизировать код на этих процессорах, чем разумный человек.

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

• Чтобы прочитать разборки дампов при отладке, что я иногда делаю даже сегодня.
• Работа с нестандартными функциями ЦП, например, в этом модном графическом режиме.
• Написание компилятора - предоставляет промежуточный, понятный человеку формат для перевода языков более высокого уровня.

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

Пока граница движется, всегда есть место для сборки.

15 лет назад ваш велосипедный одометр был механическим, микроволновая печь была в аналоговой схеме, пульт ДУ был в цифровой схеме, спутниковый ТВ-тюнер был написан на ассемблере, прошивка телефона была на C, а компьютерный апплет на Java.

7 лет назад микроволновая печь была в цифровой схеме, телевизионный пульт был написан на ассемблере, телевизионная приставка была написана на C, ваш телефон работал на основе Java-интерфейса.

В настоящее время велосипедный одометр находится в цифровой схеме, микроволновая печь получает прошивку в сборе, ТВ-пульт имеет прошивку на C, ТВ-приставка работает на Java, ваш телефон получил Linux.

Хотите поспорить, следующие 7 лет? По мере того, как все больше технологий приобретают более совершенные языки управления, сборка получает новые основания и будет продолжать их получать. Посмотрите, что сегодня делается с помощью механических или аналоговых схем. Вы можете сделать ставку на сборку там через несколько лет. Ваш выключатель света? Твой водопроводный кран? Твой чайник? Твоя зубная щетка?

Всегда будет новое устройство, прибор, игрушка, обычный предмет, который будет запрограммирован в сборке.

Я основываю это в первую очередь на ассемблерах, которые я использовал - в первую очередь на MASM, NASM и (в меньшей степени) TASM. В некоторых более поздних версиях TASM были (есть?) Некоторые функции для поддержки ОО, но я не использовал их много, и я не пытаюсь комментировать их.

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

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

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

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

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

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

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

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

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

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

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

В таких областях, как криптография, вы можете использовать его таким же образом.

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

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

И доступность персонала, это зависит от того, я полагаю, что если вы спросите в Intel, Qualcomm, ... у них должен быть большой список программистов по сборке (это как если бы вы спросили у себя на рабочем месте «сколько здесь водителей грузовиков?» Подумайте не много, но это не значит, что их нет в других местах. Что произойдет, если вы спросите: «Сколько здесь водителей автомобилей?»).

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

1. Не нужно изучать ассемблер, если вы собираетесь заниматься программированием на Visual Basic и MS.
2. Не нужно учиться сборке, если вам не нужно делать серьезные гаджеты для микроконтроллеров.
3. Не нужно изучать ассемблер, если у вас есть большой объем памяти, когда вы работаете с микроконтроллером (бог помогает вам, взаимодействуя с микроконтроллером)
4. Не нужно изучать сборку, если вы не хотите, чтобы бог как власть над вашим микроконтроллером / микропроцессором.
5. Не знать сборку - все равно что знать айсберг. Вы можете увидеть 25% того, что у вас есть, и ваши способности к микрофону, а 75% вы никогда не узнаете и не поймете
6. Попробуйте запустить ОС Kolibris полностью написанную на ассемблере !!! Вы видели ОС, которая загружается менее чем за 5 секунд, а приложение запускается с помощью 1 секунды щелчка мыши.
7. Современные компиляторы имеют функции общего назначения в бэкэнде, и, следовательно, конечный сгенерированный код будет тяжелым по сравнению с Assembly.

Сборка похожа на Наташу Романову из Мстителей. Это очарование и магия. Во-первых, это укусит вас, но поверьте мне, вы никогда не забудете вкус.