Обсуждение статьи "Зачем он нужен, этот ассемблер?"
Читайте также:
- статью "Зачем он нужен, этот ассемблер?"
- дополнение Геннадия Майко
Нам приходят письма, в которых читатели излагают свои соображения, сомнения и возражения по теме, обсуждаемой в статье Зачем он нужен, этот ассемблер? Последнее мы получили совсем недавно от MemoBreaker'а. Автор излагает в нем мнение, во многом совпадающее с мнением других людей, чьи письма мы получали ранее и обсуждали в приватных беседах по е-мэйлу. И поскольку эта точка зрения изложена в письме MemoBreaker'а наиболее полно, мы с удовольствием и благодарностью публикуем его с разрешения автора:
| Hello assembler.ru, Вот прочитал я вашу статью: "зачем он нужен, этот ассемблер?". И возникло у меня несколько соображений по этому поводу... Сразу отмечу, что сам я начинающий ассемблерщик (на PC, а вообще АСМ я знаю еще с Z80). Я не согласен с некоторыми утверждениями этой статьи: 0) Насчет ООП - все правильно, нормально в нем разобраться мне еще не удалось, хотя я надеюсь изучить С++. Далеко не каждый из знакомых мне С++ программистов смог нормально рассказать что такое полиморфизм, инкапсуляция и т.д. 1) Включать в список файлов, которые необходимо создавать самому, windows.inc нет смысла. Так как если особо не извращаться и писать на ЧИСТОМ MASM'е, то данный и другие файлы с описанием API уже есть в стандартной поставке. Писать не очень большие проги на масме гораздо удобнее и, по-моему, быстрее, нежели использовать монструозную Visual Studio. 2) Насчет размера файлов асма и С++ все в корне не верно! Если вы что-то сравниваете, то необходимо провести несколько сравнений: во-первых минимальное приложение на асме, выводящее только MessageBox, занимает, если не ошибаюсь полтора килобайта (меньше по-моему Винда не позволяет); во-вторых минимальное приложение, имеющее функцию WinMain, занимает 4608 байт(включая иконку, без оной - 3584); в-третьих нужно сравнивать и более серьезные проекты, причем, чем больше функций у программы, тем больше выигрыш по размеру при программировании на ассемблере. В результате если написать WordPad на ассемблере и на С++, то ассемблерная прога будет в несколько раз меньше, нежели СИшная. 3) Неудобство ассемблера заключается в том, что иногда простые ошибки очень сложно отловить, так, например, было с моей (и The Byte Reaper'а тоже) программой UIN2IP. Суть в том, что в MASM32 изначально были допущены ошибки во встроенной подпрограмме (из MASM32.lib) конвертации ASCII to DWORD, есть в масме и еще пара ошибочек, но менее существенных. В отношении ошибок С++ тоже есть в чем упрекнуть, бывали случаи, когда С++ сильно ругался на куски кода, которые ошибки (по крайней мере в теории) не имели. Хуже всего, когда на код ругается линкер - понять в чем ошибка становится гораздо сложнее. 4) Есть еще несколько применений ассемблера: - на нем удобно писать такие вещи как VxD драйвера (не знаю возможно ли это на С++) - ассемблер используется в критичных к скорости выполнения программах (можно, конечно, и INLINE, но как сами говорили "можно и отверткой в ухе...") Только не надо говорить, что современные процессоры позволяют добиваться приемлемых скоростей и на С++, представьте, что вы пишете движок для рендеринга, но не используя ускоритель. В данном случае С++ отстанет от асма процентов на 50 точно (если писать под конкретный процессор на ассемблере). Другой пример, более реальный, - вы пишете программу, проводящую большое количество вычислений (тот же подбор пароля), вот здесь-то скорость и пригодится как нельзя лучше! Ну вот в принципе и все претензии. Надеюсь что они будут рассмотрены и учтены :) -- Best regards, MemoBreaker P.S. Кстати, по моему личному мнению лучшее место для ассемблера в современной индустрии программо-строения - различные .DLL , в них исчезают некоторые недостатки асма и проявляются достоинства: - почти всегда отсутствует интерфейс, следовательно над ним не придется мучиться. - необходима высокая скорость работы, для чего асм подходит лучше всего (пример: сжатие MP3 или MPEG; пользователь как всегда хочет побыстрее!) - также возможна оптимизация под различные MMX, 3D-NOW!, SSE и т.д. |
MemoBreaker в работает с пакетом MASM32 и считает его лучшим вариантом ассемблера для PC (в письме, говоря об ассемблере, он имеет в виду именно этот пакет). В качестве основы для рабочей среды он предпочитает не Visual Studio, а:
- MASM32
- Win32api.hlp
- Aditor v2.x (текстовый редактор)
- парочку утилит
- SoftIce
В аргументах MemoBreaker'а есть многое, с чем можно согласиться. Например, с тем, что MASM32 - действительно идеальное средство для разработки ассемблерных приложений под Windows. И входящий в его состав файл windows.inc, который весит сейчас уже больше 800 Кбайт - действительно освобождает программиста от необходимости создавать этого монстра самому, потому что сделан достаточно хорошо, со знанием специфики и, что самое главное, постоянно обновляется. И компилятор ml.exe, который входит в пакет - всегда самой последней версии. И это при всем при том, что Microsoft не имеет к MASM32 никакого отношения (ну разве что компилятор родом оттуда). Потому что MASM32 - это детище независимых разработчиков во главе с Iсzelion'ом.
Вы всегда можете найти самую свежую версию пакета MASM32 на его официальном сайте. Кстати, дизайн сайта достаточно красноречиво говорит о дворянском происхождении MASM32, что, впрочем, ничуть не умаляет уважения к титаническому труду создателей пакета.
Но некоторые положения статьи, которые вызывают возражения у наших корреспондентов, хотелось бы пояснить.
Собираясь ставить эксперимент по сравнению ассемблерной и сишной версий MyCall, мы изначально хотели наглядно показать преимущества ассемблерной программы. У нас совсем не было планов показывать, что никаких радикальных преимуществ нет, а вот очевидные недостатки (в первую очередь - большая трудоемкость) - имеются. Мало того, мы ведь вложили в этот эксперимент несколько больше, чем вы, дорогие читатели, в прочтение нашей статьи. И поэтому вы должны представить себе наше разочарование конечными результатами.
Проведенный эксперимент совершенно не претендует на роль истины в последней инстанции. MemoBreaker предлагает провести несколько сравнений: от минимального приложения до большого проекта, и только тогда делать выводы. Наверное, такой масштабный эксперимент дал бы много свежей пищи для размышлений. К сожалению, ничего подобного мы нигде не встречали ранее, да и вряд ли встретим когда-либо. По нашим наблюдениям, то, что сделали мы с MyCall - единственная реальная попытка подтвердить (или опровергнуть?) на практике так часто выдвигаемый тезис о прекрасной приспособленности ассемблера для создания приложений для Windows.
И если абстрагироваться от оптимистических оценок, и опираться только на сухие результаты этого единственного эксперимента, то мы вынуждены повторить неутешительный вывод, уже сделанный в оригинале статьи. Нет никаких причин разрабатывать приложения для Windows на ассемблере, за исключением одной-единственной: личного предпочтения разработчика.
Другое дело, следует ли считать эту причину существенной. По нашему мнению - да, стоит. Потому что мы глубоко убеждены, что склонность к программированию на ассемблере - это не следствие образования или опыта работы, а в первую очередь следствие типа мышления данного конкретного индивидуума. И этот тезис мы повторяли и будем повторять на страницах сайта. Начиная с шуточного психологического теста и кончая этими вполне серьезными рассуждениями.
Современное программирование базируется на абстракции, причем чем дальше - тем больше. Это естественный путь, проложенный от табуляторов первых ламповых ЭВМ до той далекой точки за горизонтом, где машинные языки в конечном итоге сольются с высшим проявлением абстракции - нормальным человеческим языком.
К сожалению, дар абстракции дан людям не в равной степени. Наверное, в этом проявляется рудиментарное наследие каменного века, когда одни индивидуумы абстрактно загоняли мамонтов в ловчие ямы, а другие вполне конкретно мочили несчастных сверху булыжниками и дубинами. В результате у первых больше развилось интуитивное правое полушарие головного мозга, а у вторых - рациональное левое. И теперь, по причине отсутствия мамонтов, первые занялись программированием на C++, а вторые - на ассемблере.
Еще раз сформулируем нашу позицию касательно размера приложения, выработанную в результате эксперимента с MyCall и на основании собственного опыта разработки приложений для Windows:
- Разработка небольших приложений на ассемблере не дает ощутимых преимуществ по объему кода по сравнению с C++, а вернее, C, потому что в таких приложениях объектно-ориентированные возможности C++ обычно неприменимы. Пример тому - MyCall.
- Что касается больших приложений, то однозначно выявить преимущество ассемблера перед C++ по объему кода практически не представляется возможным. В таких приложениях существенную роль играют диктуемые языком принципы организации программ. Ассемблер предлагает программисту хаотический стиль, и приходится применять усилия и специальные приемы (см., например, статью Лептонный стиль программирования) для преодоления этого недостатка языка. C++, напротив, стимулирует формирование у программиста объектно-ориентированного стиля, и лишь неспособность или нежелание воспринять его приводит к отказу от этого стиля в пользу хаотического. А по-разному организованные программы становятся практически несравнимыми, даже если решают одну и ту же задачу.
- Еще более неочевидным становится гипотетическое преимущество ассемблера в объеме кода, если вспомнить, что приложения для Windows далеко не полностью состоят собственно из кода. Более того, в массе случаев код занимает в них меньшую часть. А гораздо больший объем занимают разнообразные данные: ресурсы, структуры, таблицы и прочее, прочее, прочее. Понятно, что данные в своем большинстве инвариантны к языку, и, следовательно, их наличие маскирует преимущество ассемблера в компактности кода.
- Плюс к сказанному: современные компиляторы C++ (в частности, Visual C++), при установленном флажке "Оптимизация по объему" дают практически оптимальный код, лишь в малой степени уступающий коду, написанному вручную на ассемблере. Более того, простая небрежность, лень или неполное знание ассемблерщика способны легко разрушить его призрачное преимущество. А вот глупому компилятору C++ такие человеческие слабости незнакомы - он оптимизирует код всегда.
Похожие аргументы мы высказываем и при рассмотрении преимуществ ассемблера в быстродействии:
- Многозадачная операционная среда, каковой является Windows, распределяет ресурсы производительности компьютера отнюдь не по признаку того, на каком языке написано приложение. Вытесняющая многозадачность, не спрашивая желания нашего приложения, выделяет ему тот временной ресурс, который считает нужным, а остальное время отдает другим потокам, маскируя то преимущество в быстродействии, которое мог бы дать ассемблерный код.
- Развитый сервис API, освободивший ассемблерщика от огромного объема рутинной работы, играет в данном случае злую шутку: вызовы API обрабатываются с одной и той же скоростью вне зависимости от того, на каком языке написано приложение, и в силу этого также стирается преимущество в скорости ассемблерного кода.
- Такой же эффект производит и система сообщений, без которой не обходится ни одно уважающее себя оконное приложение. Ее обслуживает очень приличный кусок кода, локализованного вне приложения, и отнимающего у приложения свою немалую долю ресурса производительности.
- В случае разработки приложений с активным использованием графики большая часть гигантской работы по ее обслуживанию все больше ложится на "железо" - 2d и 3d ускорители, которым также безразлично, на чем написано наше приложение.
- Наконец, современные компиляторы C++ при установленном флажке "Оптимизация по времени" генерируют практически оптимальный код, который дает максимальную скорость так же независимо от настроения и знаний программиста, как и минимальный размер в случае оптимизации по размеру.
В подтверждение этих тезисов приведем письмо, полученное от Dmitry S. Bobrik (спасибо ему!) буквально во время написания этой статьи:
|
Hello! Можете себе представить - компиленый Сишный код работает БЫСТРЕЕ написаного на Асме! Единственное разумное объяснение - оптимизатор MSVC пишет код учитывая особенности архитектуры процессоров Пентиум (ну и выше...). А на Асме все то ручками, да ручками... обидно даже :-/ wbr, Dmitry http://bcsoft.da.ru http://home.tula.net/frazez |
Дмитрий сообщил, что впервые об этом эффекте он прочитал в мэйл-листе sp-forth@egroups.com
И несколько замечаний в заключение:
- Это не похороны ассемблера, хотя бы потому, что:
- ему по-прежнему есть и будет место в разработке драйверов устройств
- ему по-прежнему есть и будет место в приложениях, монополизирующих ресурсы системы:
- в играх
- в обработке потоков данных, в том числе в реальном времени
- в расчетах
- и т.д.
