Ms-dos и tasm 2.0. часть 2. turbo assembler

Три системы счисления — практическое использование.

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

Шестнадцатеричный (HEX) код удобен для современных процессоров, которые фактически развиваются на основе 16-ти разрядного процессора для персональных компьютеров Intel i8086. В исходных текстах программ практически всех языков программирования цифра обозначает по умолчанию число в десятичной системе счисления (DEC).

Десятичная система счисления более удобна (хотя и не всегда) при написании кода программ, шестнадцатеричная — неотъемлемая часть отладки, взлома, реверсивного программирования.

Двоичная система счисления (BIN) используется в основном при расстановке флагов определённых стилей объектов Windows (стили окон), но об этом попозже. Рассматривая 16 битное число в виде двоичного мы получаем великолепную возможность получить крохотный по размеру набор 16 флагов, где 1 — флаг установлен 0 — флаг снят (например, шестнадцатеричное число 4 000 соответствует двоичному 0100 0000 0000 0000 — установлен второй флаг, остальные сняты; шестнадцатеричное число 3000 соответствует двоичному числу 0011 0000 0000 0000 — установлены третий и четвёртый флаги, остальные сняты ).

Если мы хотим обозначить принадлежность числа к 16-тиричной системе счисления, то:
1. Ассемблер — добавляем к числу постфикс h (H), например: 100h = 256, 10H=16. Иногда для понимания того, что мы имеем дело с числом, в качестве префикса ставят 0 (ноль).
2. Си (С++) к числу добавляется суффикс 0x (0X).

Например: 0x100 = 100h = 0100h = 256, 0x10 = 10H = 010H = 16

Какие программы нельзя написать на ассемблере?

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

Ты при желании можешь написать на ассем­бле­ре даже веб‑сайт. В девянос­тые С был впол­не разум­ным выбором для этой цели. Исполь­зуя такую вещь, как CGI BIN, веб‑сер­вер мог вызывать прог­рамму, написан­ную на С. Через сайт получал зап­рос, а через отправ­лял резуль­тат в бра­узер. Ты можешь лег­ко реали­зовать тот же прин­цип на ассем­бле­ре.

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

  • У тебя более низ­кая про­дук­тивность, чем если бы ты работал на язы­ке высоко­го уров­ня.
  • У тво­его кода нет никакой струк­туры, поэто­му дру­гим раз­работ­чикам будет труд­но читать его.
  • Те­бе при­дет­ся писать мно­го букв. А там, где боль­ше букв, боль­ше потен­циаль­ных багов.
  • С Secure Coding здесь все очень печаль­но. На ассем­бле­ре писать так, что­бы код был безопас­ным, слож­нее все­го. На С в этом пла­не ты чувс­тву­ешь себя куда более ком­фор­тно.

Да, все мож­но написать на ассем­бле­ре. Но сегод­ня это нецеле­сооб­разно. Луч­ше пиши на С. Ско­рее все­го, будет безопас­нее, быс­трее и более лаконич­но.

От редакции

Ав­тор статьи — боль­шой пок­лонник С и нас­тоятель­но рекомен­дует этот язык. Мы не будем лишать его такой воз­можнос­ти. С — отличная шту­ка и помога­ет как осво­ить основные кон­цепции прог­рамми­рова­ния, так и про­чувс­тво­вать прин­ципы работы компь­юте­ра. Одна­ко при выборе язы­ка для изу­чения ты можешь руководс­тво­вать­ся самыми раз­ными сооб­ражени­ями. Нап­ример:

  • На­до учить Python или Lua, что­бы момен­таль­но получать резуль­таты. Это мотиви­рует!
  • На­до учить Scheme или Haskell из тех же сооб­ражений, что в шко­ле учат алгебру, а не, к при­меру, авто­меха­нику.
  • На­до учить Go для того же, для чего C, но в 2020 году.
  • На­до учить JavaScript и React.js, что­бы как мож­но быс­трее най­ти работу.
  • На­до учить Java, что­бы мак­симизи­ровать зарабо­ток.
  • На­до учить Swift, потому что почему нет?
  • На­до учить HolyC, что­бы сла­вить Гос­пода.
  • На­до учить Perl во имя Сатаны.

И так далее. Ответ на воп­рос о том, с какого язы­ка начать, зависит от мно­гих фак­торов, и выбор — дело инди­виду­аль­ное.

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

Ассемблер — программирование или искусство?

Скажем так, все зависит от того, в чьих руках он находится. Ассемблер — это первичный элемент мира процессора, из сочетаний этих элементов складывается его душа, его самосознание. Подобно тому, как вся музыка, написанная в истории человечества, состоит из сочетаний семи нот, так и сочетание ассемблерных команд наполняет компьютерный мир цифровой жизнью. Кто знает лишь три аккорда — это «попса», кому же известна вся палитра — это классика.

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

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

Ассемблер и терминатор

Не так давно Джеймс Кэмерон выпустил в свет 3D-версию второго «Терминатора», и в качестве интересного исторического факта можно отметить один любопытный момент из жизни киборга-убийцы…

Кадр из фильма «Терминатор»

Здесь мы видим «зрение» терминатора, а слева на нем отображается ассемблерный листинг. Судя по нему, знаменитый Уничтожитель работал на процессоре MOS Technology 6502 либо на MOS Technology 6510. Этот процессор впервые был разработан в 1975 году, использовался на компьютерах Apple и, помимо всего прочего, на знаменитых игровых приставках того времени Atari 2600 и Nintendo Entertainment System (у нас более известной как Dendy). Имел лишь три 8-разрядных регистра: А-аккумулятор и два индексных регистра X и Y. Такое малое их количество компенсировалось тем, что первые 256 байт оперативной памяти (так называемая нулевая страница) могли адресоваться специальным образом и фактически использовались в качестве 8-разрядных или 16-разрядных регистров. У данного процессора было 13 режимов адресации на всего 53 команды. У терминатора идет цепочка инструкций LDA-STA-LDA-STA… В семействе 6502 программы состояли чуть менее чем полностью из LDA/LDY/LDX/STA/STX/STY:

Чтение и запись в порты ввода-вывода также выполнялись этими командами, и программа терминатора имеет вполне осмысленный вид, а не представляет собой бестолковую фантазию сценариста: MOS Technology 6502 / Система команд.

IDA — Interactive DisAssembler.

IDA — любимый дизассемблер известного хакера Криса Касперского. Многие отладчики и дизассемблеры позавидовали бы глобальности этой программы. Из особенностей можно отметить возможность написания достаточно сложных программ-макросов на встроенном Си-подобном языке, содержащих алгоритмы анализа и отладки приложений.

Получил своё развитие в среде Windows, причем понимает 64 битный код. Генерирует логическую схему программы. При помощи декомпилятора Hex-Ray из дизассемблерного кода создаёт достаточно живой код на Си.

Ассемблер для dos — интерактивный дизассемблер IDA.

Наряду со своими внушительными возможностями обладает одним недостатком — сложностью изучения в полном объёме. Необходимо запомнить кучу горячих клавиш, особенностей и фишек. IDA требует такого же изучения, как отдельный язык программирования в приложении к конкретной среде разработки.

Мы рассмотрели только наиболее удобные и функциональные отладчики и дизассемблеры программ операционной системы MS-DOS, которые будем использовать при дальнейшем изучении ассемблера.

NASM

Транслятор NASM (расшифровывается как NetwideAssembler – Ассемблер
Шириной Во Всю Сеть или просто Расширенный Ассемблер) вырос из идеи, поданной
на comp.lang.asm.x86 (или возможно на alt.lang.asm — сейчас точно никто и
не помнит), когда не было ни одного хорошего свободного ассемблера под x86. FASM’а тогда еще не
существовало. MASM/TASM стоили денег и работали
только под MS-DOS/Windows. Единственный более-менее
работающий транслятор под UNIX –
GAS (GNUAssembler) завязан на
компилятор GCC и имеет
такой ужасный синтаксис, что писать на нем могут только мазохисты (и ведь
примеров программ, запрограммированных на GAS’е практически нет!). Остальные ассемблеры (типа A86, AS86) не позволяют писать 16/32
разрядный код или раздаются практически без документации.

Кончилось это
дело тем, что группа программистов во главе с Петром Анвином (Peter Anvin) решила
разработать собственный ассемблер и это у нее получилось! MASM-подобный синтаксис, достаточно мощная
макросистема (впрочем, несовместимая с MASM’ом и ничего не знающая об union’ах вместе с кучей других
полезных фич), поддержка всей линейки x86 процессоров вплоть до IA64 в x86-режиме,
богатство выходных файлов (bin, aout, aoutb, coff, elf, as86, obj, win32, rdf,
ieee), генерация отладочной информации в форматах Borland, STABS и DWARF2 вкупе
с портами под MS-DOS, Windows, Linux и BSD обеспечили NASM’у неслабую популярность, однако,
без ярко выраженного фанатизма, характерного для FASM’а. Количество ошибок в трансляторе довольно
велико, причем в отличии от _работающих_ продуктов (MASM/TASM) при «хитрых ошибках» NASM не падает, а генерирует ошибочный
(по структуре) объектный файл. Вот и ищи как он его сгенерировал чем хочешь
(даже матерым хакерам это сложно, а нормальный программист может даже и не
пытаться). И, как это принято в OpenSource-community, полное игнорирование
баг-репортов «неудобных» для авторов (разработки даже утверждают, что
ошибок в их трансляторе вообще нет, в смысле им не известен ни один). Тем не
менее, в последней версии NASM’а,
в зависимости от значения ключа -On, код может сгенерироваться в 2х или более
экземплярах, или может пропасть весь экспорт (pubdef’ы).

К минусам NASM’а можно отнести
отсутствие поддержки уникода, платформы AMD x86-64, формата отладочной информации CodeView и некоторые странности синтаксиса.
В частности, команда «mov eax, 1» не оптимизируется и транслятор
умышленно оставляет место для 32-разрядного операнда. Если же мы хотим получить
«короткий» вариант, размер операнда необходимо специфицировать явно:
«mov eax, byte 1», что очень сильно
напрягает или… использовать опцию «-On» для автоматической
оптимизации.

Также
необходимо принудительно указывать длину переходов short или near, иначе очень легко нарваться на
ругательство «shortjumpoutofrange».
Впрочем, опять-таки, существует возможность настроить транслятор на генерацию near-переходов по умолчанию.

Гораздо хуже,
что NASM не помнит типы
объявляемых переменных и не имеет нормальной поддержки структур (впрочем, самое
понятие «нормальности» структур в ассемблере весьма растяжимо и
каждый волен трактовать его по своему).

Из мелких
недочетов можно называть невозможность автоматического генерации короткого
варианта инструкции «push imm8» и отсутствие контроля за
соответствием транслируемых инструкций типу указанного процессора (команда
«cpuid» под «.486» ассемблируется вполне нормально, а ведь
не должна).

Непосредственная
трансляция примеров из SDK/DDK под NASM’ом невозможна, так что
разрабатывать на нем драйвера под Windows может только очень крутой поклонник или извращен. NASM — один из лучших
ассемблеров под Liux/BSD, а вот под Windows его позиции уже не
так сильны (в основном из-за неполной совместимости с MASM’ом).

Литература и веб ресурсы

Beginners

  1. Абель П. Язык Ассемблера для IBM PC и программирования. – М.: Высшая школа, 1992. – 447 с.
  2. Брэдли Д. Программирование на языке ассемблера для персональной ЭВМ фирмы IBM.– М.: Радио и связь, 1988. – 448 с.
  3. Галисеев Г.В. Ассемблер IBM PC. Самоучитель.: – М.: Издательский дом «Вильямс», 2004. – 304 с.: ил.
  4. Дао Л. Программирование микропроцессора 8088. – М.: Мир, 1988. – 357 с.
  5. Жуков А.В., Авдюхин А.А. Ассемблер. – Спб.: БХВ-Петербург, 2003. – 448 с.: ил.
  6. Зубков С.В., Ассемблер для DOS, Windows и UNIX. – М.: ДМК Пресс, 2000. – 608 с.: ил. (Серия «Для программистов»).
  7. Ирвин К. Язык ассемблера для процессоров Intel, 4-е издание.: пер. с англ. – М.: Издательский дом «Вильямс», 2005. – 912 с.: ил. – Парал. тит. англ.(см. также свежее 7-ое издание в оригинале)
  8. Нортон П., Соухэ Д. Язык ассемблера для IBM PC.– М.: Компьютер, 1992.– 352 с.
  9. Пильщиков В.Н. Программирование на языке ассемблера IBM PC.– М.: ДИАЛОГ-МИФИ, 1994–2014 288 с.
  10. Скляров И.С. Изучаем ассемблер за 7 дней www.sklyaroff.ru

Advanced

  1. Касперски К. Фундаментальные основы хакерства. Искусство дизассемблирования. – М.: СОЛОН-Пресс, 2004. 448 с. – (Серия «Кодокопатель»)
  2. Касперски К. Техника отладки программ без исходных текстов. – Спб.: БХВ-Петербург, 2005. – 832 с.: ил.
  3. Касперски К. Компьютерные вирусы изнутри и снаружи. – Спб.: Питер, 2006. – 527 с.: ил.
  4. Касперски К. Записки исследователя компьютерных вирусов. – Спб.: Питер, 2006. – 316 с.: ил.
  5. Кнут Д. Искусство программирования, том 3. Сортировка и поиск, 2-е изд.: пер. с англ. – М.: Издательский дом «Вильямс», 2003. – 832 с.: ил. – Парал. тит. англ.
  6. Колисниченко Д.Н. Rootkits под Windows. Теория и практика программирования «шапок-невидимок», позволяющих скрывать от системы данные, процессы, сетевые соединения. – Спб.: Наука и Техника, 2006. – 320 с.: ил.
  7. Лямин Л.В. Макроассемблер MASM.– М.: Радио и связь, 1994.– 320 с.: ил.
  8. Магда Ю. Ассемблер для процессоров Intel Pentium. – Спб.: Питер, 2006. – 410 с.: ил.
  9. Майко Г.В. Ассемблер для IBM PC.– М.: Бизнес-Информ, Сирин, 1997.– 212 с.
  10. Уоррен Г. Алгоритмические трюки для программистов, 2-е изд.: пер. с англ. – М.: Издательский дом «Вильямс», 2004. – 512 с.: ил. – Парал. тит. англ.
  11. Скляров И.С. Искуство защиты и взлома информации. – Спб.: БХВ-Петербург, 2004. – 288 с.: ил.
  12. Уэзерелл Ч. Этюды для программистов: Пер. с англ. – М.: Мир, 1982. – 288 с., ил.
  13. Электронная библиотека братьев Фроловых www.frolov-lib.ru
  14. Чекатов А.А. Использование Turbo Assembler при разработке программ.– Киев: Диалектика, 1995.– 288 с.
  15. Юров В. Assembler: специальный справочник.– Спб.: Питер, 2001.– 496 с.: ил.
  16. Юров В. Assembler. Практикум. 2-е изд. – Спб.: Питер, 2006. – 399 с.: ил.
  17. Юров В. Assembler. Учебник для вузов. 2-е изд. – Спб.: Питер, 2007. – 637 с.: ил.
  18. Пирогов В. Assembler учебный курс. 2001 Нолидж
  19. Пирогов В. АССЕМБЛЕР учебный курс 2003 Нолидж-БХВ
  20. Пирогов В. Assembler для windows 
    1-ое издание ― М.: изд-во Молгачева С.В., 2002 
    2-ое издание ― СПб.:. БХВ-Петербург, 2003 ― 684 с.: ил. 
    3-ье издание ― СПб.:. БХВ-Петербург, 2005 ― 864 с.: ил. 
    4-ое издание ― СПб.:. БХВ-Петербург, 2012 ― 896 с.: ил.
  21. Пирогов В. Ассемблер на примерах. ― СПб.:. БХВ-Петербург, 2012 ― 416 с.: ил.
  22. Пирогов В. АССЕМБЛЕР и дизассемблирование. ― СПб.:. БХВ-Петербург, 2006. ― 464 с.: ил.
  23. Пирогов В. работа над книгой ’64-битовое программирование на ассемблере (Windows,Unix)’. В книге рассматривается программирование на fasm в 64-разрядных Windows и Unix
  24. Юров В., Хорошенко С. Assembler: учебный курс.– Спб.: Питер, 1999. – 672 с.
  25. Ю-Чжен Лю, Гибсон Г. Микропроцессоры семейства 8086/8088. Архитектура, программирование и проектирование микрокомпьютерных систем.– М.: Радио и связь, 1987.– 512 с.
  26. Agner Fog: Software optimization resources (assembly/c++) 1996 – 2017. Веб-страница
  27. Intel 64 and IA-32 Architectures Optimization Reference Manual
  28. Intel 64 and IA-32 Architectures Software Developer’s Manual Volume 1: Basic Architecture
  29. Intel 64 and IA-32 Architectures Software Developer’s Manual Volume 2A: Instruction Set Reference, A-M
  30. Intel 64 and IA-32 Architectures Software Developer’s Manual Volume 2B: Instruction Set Reference, N-Z
  31. Intel 64 and IA-32 Architectures Software Developer’s Manual Volume 3A: System Programming Guide, Part 1
  32. Intel 64 and IA-32 Architectures Software Developer’s Manual Volume 3B: System Programming Guide, Part 2
  33. Leiterman J.C. 32/64-BIT 80×86 Assembly Language Architecture. 2005, Wordware Publishing, Inc (568 pages) 2320 Los Rios Boulevard Plano, Texas 75074
  34. Turbo Assembler Version 3.2 User’s Guide Borland International. Inc 1800 Green Hills Road P.O. BOX 660001, Scotts Valley, CA 95067-0001
  35. Статьи с сайта wasm.in
  36. Статьи с сайта sasm.narod.ru
  37. Сайт MASM32 и форум
  38. Сайт FASM и форум
  39. Сайт NASM

Создаём исполняемый файл PRG.COM.

Для достижения нашей цели делаем следующее.

;Строка, после точки с запятой является комментарием
;и не обрабатывается ассемблером
; prg.asm — название файла.
.model tiny ; создаём программу типа СОМ
.code ; начало сегмента кода
org 100h ; начальное значение смещения программы в памяти — 100h
start:
mov ah,9 ; номер функции DOS — в АН
mov dx,offset message ; адрес строки — в DX
int 21h ; вызов т.н. «прерывания» — системной функции DOS
ret ; завершение СОМ-программы
message db «Hello, World!»,0Dh,0Ah,’$’ ; строка для вывода
end start ; конец программы.

1
2
3
4
5
6
7
8
9
10
11
12
13

;Строка, после точки с запятой является комментарием
;и не обрабатывается ассемблером
; prg.asm — название файла.

.modeltiny; создаём программу типа СОМ

.code; начало сегмента кода

org100h; начальное значение смещения программы в памяти — 100h

start

movah,9; номер функции DOS — в АН

movdx,offsetmessage; адрес строки — в DX

int21h; вызов т.н. «прерывания» — системной функции DOS

ret; завершение СОМ-программы

messagedb»Hello, World!»,0Dh,0Ah,’$’; строка для вывода

endstart; конец программы.

В папке D:\TASM.2_0\TASM\ находим «батник» ASM-COM.BAT со следующим текстом:

tasm.exe prg.asm
tlink.exe /t /x prg.obj

1
2

tasm.exeprg.asm

tlink.exetxprg.obj

Первая строка — запуск транслятора с названием нашего файла с кодом, расположенного в одной директории с транслятором.

Вторая строка — запуск компилятора с параметрами /t /x и название объектного файла — prg.obj, получившегося в результате выполнения первой команды.

Чтобы посмотреть список всех возможных параметров с пояснениями для файлов tasm.exe и tlink.exe необходимо запустить эти программы без параметров. Если вы сделаете это, не выходя из оболочки NC, то, чтобы просмотреть чистое окно DOS нажмите Ctrl+O, чтобы вернуться в NC, нажмите сочетание клавиш повторно.

После запуска ASM-COM.BAT в этой же директории появится файл prg.com. Запустив его мы увидим сообщение «Hello World!» в окне MS-DOS (при необходимости просмотра, снова применяем Ctrl+O).

Батник ASM-EXE.BAT предназначен для создания исполняемого файла формате *.EXE (предусматривает раздельную сегментацию для кода, данных и стека — наиболее распространённый формат исполняемых файлов DOS).

Батник COMPLEX.BAT предназначен для создания исполняемых файлов из двух файлов кода (названия обязательно должны быть prg.asm, prg1.asm).

Наша первая программа на ассемблере прекрасно работает!

Почему следует изучать язык ассемблера?

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

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

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

Иными словами, до тех пор пока существуют процессоры, ассемблер будет необходим.

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

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

[править] Область применения

  • Популярен для допиливания зацикливаемых кусков программы… в роли напильника. Перепиливание критических участков кода может принести PROFIT, а может и не принести. В любом случае, заниматься таким перепиливанием стоит только тогда, когда у вас на руках уже полностью работающий алгоритм, который можно было бы ускорить, а не наоборот.
  • Для использования в софтине новых команд, доступных в новых процессорах. Компилятор хоть и оптимизирует код высокого уровня при компиляции, но… практически никогда не способен генерировать инструкции из расширенных наборов команд типа AVX, СTV, XOP и т. п. Потому что команды в процессоры добавляют быстрее, чем в компиляторах появляется логика для генерации этих команд.
  • Используется для написания кода, создание которого невозможно (или затруднено) на языках высокого уровня, например, получение дампа памяти/стека. Даже когда аналог на языке высокого уровня возможен, профит от языка ассемблера может быть значительным в разы. Например, реализация подсчета среднего арифметического двух чисел с учётом переполнения для x86 процессоров занимает всего 2 команды (сложение с выставлением флага переноса и сдвиг с заёмом этого флага). Аналог на языке высокого уровня ((long) x + y) >> 1
    1. может не работать в принципе, ведь sizeof(long) == sizeof(int). Ну или может бомбануть, как это было на ракете Ариан-5 (64-ичные переменные с плавающей запятой float преобразовывались в 16 бит фиксированных, когда программа дошла до 32767+1, у ракеты включилась система «самоуничтожение на случай попадания в мир КГБ» прямо на космодроме.
    2. при компиляции конвертируется в чуть менее чем дохрена команд процессора.

Ещё пример: перемножение чисел с фиксированной запятой в языке, в который не вшита поддержка такого формата чисел. На ассемблере это умножение eax на edx с сохранением 64-битного результата в edx:eax с последующим сдвигом вправо (shrd). На ЯВУ это выглядит либо как (x*y)>>16, что не даёт верный результат при выходе результата умножения за 32 бита, либо как (int64(x)*y)>>16, что конвертируется в дохрена команд.
Впрочем, в данных примерах современные компиляторы умеют правильно понимать намерения программиста и генерировать оптимальный код.

  • В вузах изучается для вливания в МНУ студентоты познаний об устройстве и работе компьютера на уровне повыше кликанья мышкой по окошкам. Отличное лекарство от быдлокодерства (ну, а для оказавшихся неспособными осилить, соответственно — окончательное решение).
  • Является единственным языком программирования для создания достойных инфекторов — Cih, Sality, Sinowal.
  • Чуть более чем половина программ для GPU пишутся на ассемблере, наряду с использованием языков высокого уровня HLSL или GLSL. Хороший, годный шейдер обязательно содержит асму, ибо GPU — это принципиально узкое место для выделения графической составляющей в монитор (Есть, конечно и более современные методы типа использования OpenCL, но всё же ASM << C).
  • Оптимизация невъебенно затратных математических алгоритмов. Часто встречается в исходниках фильтров для так любимого видеопиратами и аниматорами винрарнейшего AviSynth.
  • Промежуточный этап между неким левым синтаксисом (не обязательно даже языком, это может быть визуальный «конструктор» программы вроде ДРАКОНа) и исполнимым кодом. Петя хочет анализ Фурье на ЦСП на участке в миллисекунду, а Вася в две? Нет проблем, нажимайте кнопочки и собирайте в проект полученные пятидесятиметровые ассемблерные сырцы, работающие с предельно возможной именно для конкретного случая скоростью. Не компилятор же отдельный писать ради Васи и Пети, честное слово.
Оцените статью
Рейтинг автора
5
Материал подготовил
Андрей Измаилов
Наш эксперт
Написано статей
116
Добавить комментарий