В начале небольшой дисклеймер — эта статья не является рекламой, я не имею к продукту ровно никакого отношения, но этот кроссплатформенный ассемблер с открытым исходным кодом вполне заслуживает небольшого обзора и может оказаться полезен, чем и хотелось бы поделиться. Автором же является программист Павел (Pavel Šrubař @vitsoft) из небольшого уютного чешского городка Vítkov. Трудится он в Чешской Почте в IT отделе.
У читателя предполагается наличие базовых знаний об устройстве компьютера, регистрах процессора и о том, как он вообще выполняет всё, о чём его просят. Статья не является исчерпывающим руководством по архитектуре и системе команд процессора, синтаксису ассемблера (это может занять книгу и не одну), но просто этакий "кик-стартер" для любопытствующих и желающих разобраться поглубже.
Нужно ли знать ассемблер в современных реалиях? Это зависит от многих факторов. Современные оптимизирующие компиляторы в общем избавляют от необходимости написания кода на ассемблере, более того, порой "самописный" код может исполняться даже медленнее кода на Си, но знание и понимание инструкций помогает находить и анализировать "узкие места" там, где проседает производительность и помогает понять тонкости устройства центрального процессора (для некоторых он так и остаётся магией). Но каждый решает сам. Зачем нужен ещё один ассемблер и зачем это на хабре? Автору (ассемблера, а не статьи) были неудобны существующие решения, он решил сделать сам, так как удобно ему. Ну а будет ли это удобно читателям — решать вам.
Если ограничить кругозор ОС Windows, существует несколько макро-ассемблеров, их не так много. Если основным инструментом является Visual Studio, то будет логичен выбор ассемблера MASM. Он достаточно популярен, бесплатен и на хабре были статьи с его применением. Из альтернатив можно смело упомянуть FASM (Flat Assembler) и NASM (Netwide Assembler). В принципе у каждого есть свои плюсы и минусы. Есть и малоизвестные, например входящий в состав Pelles C. Эти ассемблеры могут отличаться синтаксисом и идеологией (кто-то может ассемблировать в объектный файл, а другие имеют встроенный линковщик) но речь не о них. Важно понимать, что на "чистом" ассемблере далеко не уехать, поэтому у них есть приставка "макро", когда можно упростить программирование при помощи макросов.
Я впервые столкнулся с ассемблером при разработке рентгеновского дифрактометра на ДВК-4, где операционная система RT11FB позволяла запустить две задачи параллельно, собственно управление дифрактометром и автоматизация эксперимента была выполнена на ассемблере MACRO-11, а математическая часть и интерфейс пользователя на Си. Там выбор ассемблера сильно упростил жизнь в 56 килобайтах памяти.
Не будем далеко ходить — домашняя страница euroassembler.eu, а скачать его можно вот отсюда, это прямая ссылка на актуальную версию https://euroassembler.eu/download/euroasm.zip. Этот ассемблер написан на себе самом, и, с одной стороны, это даёт компактность и портабельность, но с другой стороны, на него нервно реагируют эвристики некоторых антивирусов (но и виртуалки никто не отменял). Я честно попытался найти последовательность байтов, которая "триггерит" эвристику, разделяя файл пополам и отправляя половинки в VirusTotal, но так и не смог найти. Если у вас больше опыта с антивирусами — пожалуйста напишите в комментариях.
После распаковки у вас в руках будет euroasm.exe размером всего четыреста килобайт. Весь исходный код этого ассемблера открыт и доступен, его несложно пересобрать в случае необходимости.
Первая программа
Как говорили великие — единственный способ научиться программировать — это начать писать программы, давайте для начала просто сложим два числа и выведем результат в консоль (чистый "Hello, Habr!" будет состоять из одного макроса и вообще не будет содержать ни строчки на ассемблере, так что разбавим пример хотя бы mov и add).
Всё, что вам надо знать, это то, что у процессора есть Регистры (коих шестнадцать штук общего назначения) и Инструкции, которыми он оперирует.
Структура минимальной программы на этом ассемблере очень проста, вот она полностью:
EUROASM AddHabr PROGRAM Format=PE, Entry=Start INCLUDE winapi.htm, cpuext32.htm Result D 8*B Start: nop mov eax, 17 add eax, 29 StoD Result StdOutput =B"17+29=", Result TerminateProgram ENDPROGRAM
Давайте разберём все строчки, их тут десяток всего-то. Ссылки на документацию приводятся.
Программа начинается с ключевого слова EUROASM, за которым вообще говоря могут идти опции, но в этой минимальной программе они не нужны (потому что выставлены по умолчанию).
Следом идёт имя программы и ключевое слово (псевдоинструкция) PROGRAM, перед которой находится имя программы, за которым две опции — формат PE, что означает Portable Executable (если бы мы писали DLL, то было бы очевидно DLL), и точка входа (может быть любая строка — Start, Begin или main — всё, что хотите, вы видите эту метку чуть ниже). Кстати, в одном файле может быть несколько секций PROGRAM, тогда у них должны быть разные имена, и в этом случае компиляцией одного файла можно сразу получить несколько исполняемых файлов или библиотек.
Затем следует INCLUDE — здесь мы включаем две библиотеки макросов, из одной мы возьмём макрос перевода числа в строку, а из второй — вывод в консоль. И расширение .htm — это не ошибка — да, вы можете хранить код в HTML. Включать можно не только библиотеки, но вообще любые файлы, обычно им даётся расширение *.inc.
Result D 8*B резервирует восемь байт для результата (для короткого числа в этом примере нам больше и не надо).
Следом идёт метка Start: , это входная точка программы, куда будет передано выполнение после загрузки в память, и инструкция nop. Наличие оператора nop помогает евроассемблеру отделить мух от котлет код от данных — так работает автосегментация. Это позволяет избавиться от явного указания секций [.text] и [.data]. Также в отладчике этот NOP удобно видеть как "метку" начала программы и начала отладки.
mov eax, 17 заносит значение 17 в регистр EAX, а add eax, 29 добавляет туда 29. Числа 17 и 29 я взял не случайно — 1729 это симпатичное число Рамануджана-Харди. Регистр не важен — можете писать MOV EAX,17, так предпочитает автор, но в основном нынче используются строчные буквы, время семибитных кодировок кануло в лету.
StoD Result берёт значение RAX (там 46) и переводит его в ASCII строку "46", копируя в буфер, на который указывает Result. Как бы аналог itoa(). На самом деле перевод числа в строку на чистом ассемблере — не такая уж тривиальная задача, загляните в исходник по ссылке выше, там больше полусотни инструкций.
Ну а StdOutput =B"17+29=", Result выводит на экран 17+29=46. =B — это "синтаксический сахар", позволяющий "заинлайнить" строковую константу-литерал, кроме того макрос StdOutput может принимать переменное число аргументов. Здесь также надо понимать, что для вывода в консоль надо ведь вначале получить хендл через GetStdHandle(), затем писать через WriteConsole(), при этом строка может содержать Юникод, вот от всего этого нас и избавляет данный макрос.
Затем программа завершается через TerminateProgram (это тоже макрос, который вызывает ExitProcess() из kernel32.dll) и ключевое слово ENDPROGRAM (если у вас несколько программ в одном файле, то там понадобится имя программы). TerminateProgram не есть обязательная вещь — программа завершится и так, но формально пусть будет — ей можно передать код возврата ошибки.
Создайте файл AddHabr.asm, да хоть в блокноте Windows и скопируйте туда код, что был выше, сохраните этот файл там же, где находится euroasm.exe (либо скопируйте весь евроассемблер в %APPDATA%\eurotool и добавьте путь в PATH). Сборка программы осуществляется при помощи команды euroasm.exe AddHabr.asm. Всё.
Если вы скопировали всё без ошибок, то после компиляции появится файл AddHabr.exe, который и выведет это сообщение 17+29=46.
Маленький лайфхак — если вам лень ставить редактор с поддержкой ассемблер-синтаксиса, равно как и возиться с командным промптом, просто поставьте Far Manager, встроенный редактор (новый файл Shift+F4, редактирование F4) понимает ассемблер и раскрашивает код, а компиляцию можно упростить через пользовательское меню, всё вместе это будет выглядеть как-то так (как видите, все папки дистрибутива не нужны, достаточно maclib и objlib):
Нехитрый код выше оставляет широкий простор для экспериментов. Например, вы можете не хардкодить, а попросить пользователя ввести числа из консоли, давайте для разнообразия сделаем в 64 бит:
EUROASM CPU=x64 %^SourceName PROGRAM Format=PE, Width=64, Entry=Start Buffer1 D 32*B Buffer2 D 32*B Result D 32*B INCLUDE winabi.htm, cpuext64.htm Start: nop StdOutput =B"Enter 1st Operand >" StdInput Buffer1 StdOutput =B"Enter 2nd Operand >" StdInput Buffer2 LodD Buffer1 mov rbx, rax LodD Buffer2 add rax, rbx StoD Result StdOutput =B"Result:", Result TerminateProgram ENDPROGRAM
Здесь несколько небольших изменений.
Во-первых, имя программы заменено на переменную %^SourceName. Так удобнее работать в сценарии "один файл—одна программа", потому что имя будет браться из имени файла (и именно под этим именем будет создаваться исполняемый файл или библиотека DLL). Переменных там много — €ASM system %variables.
Кроме того, мы переехали на 64 бита добавлением CPU=x64 и Width=64 и соответственно поправили INCLUDE, также вместо 32-битных регистров типа EAX используется 64-бит RAX.
Затем добавлены два буфера для входных строк.
StdOutput вы уже знаете, этот макрос выведет приглашающий промпт, а вот StdInput получит данные, введённые пользователем и запишет введённое значение в буфер, на который указывает Buffer1 (как ASCII символы, включая перевод строки). Затем всё повторяется для второго операнда. Таким образом, если мы введём "42", то в буфере будут 0x34, 0x32, 0x0D, 0x0A.
Теперь нам надо конвертировать ASCII строку в значение, что-то типа atoi(), это делает макрос LodD, который возвращает значение в регистр RAX (теперь у нас 64 бит). Мы сохраним это значение в RBX, и повторим LodD для второго буфера. Теперь в RBX у нас первый операнд, а в RAX второй. Команда add RAX, RBX их складывает, и дальше всё как и выше. Важный момент — при таком использовании вы должны быть абсолютно уверены, что LodD Buffer2 не изменит значение RBX! (чтобы в этом убедиться, достаточно заглянуть в исходник макроса).
Предположим, в качестве следующего упражнения мы хотим использовать стек для хранения первого введённого операнда, затолкаем RAX в стек и вытащим его в RBX:
LodD Buffer1 push rax LodD Buffer2 pop rbx add rax, rbx StoD Result
Кстати, в этом ассемблере поддерживаются множественные переменные при работе со стеком, то есть не надо писать отдельно push rax, push ebx, а можно одной командой push rax, rbx — это удобно.
Либо можно завести временную переменную, зарезервировав восемь байт памяти:
TempVar D Q ; Reserve one qword. ; ... LodD Buffer1 mov [TempVar], rax LodD Buffer2 add rax, [TempVar] StoD Result
Можно получить значения из аргументов командной строки, для этого есть макросы GetArgCount и GetArg. В общем не бойтесь экспериментировать. Ассемблер снабжён неплохой инструкцией, кроме того довольно большим количеством примеров и проектов, в конце есть несколько для Windows, от простого консольного приложения, поддерживающего юникод до заготовки оконного приложения.
Как справедливо заметили в комментариях, этот ассемблер может "собрать" файл для Линукса в том числе, всё что нужно для этого — заменить формат PE на ELFX и включить linapi.htm вместо winapi.htm, вот минимальный код:
EUROASM HelloHabr PROGRAM Format=ELFX, Entry=Start INCLUDE linapi.htm Start: nop StdOutput =B"Hello, Habr!", Eol=yes TerminateProgram ENDPROGRAM
после сборки которого вы получите файл HelloHabr.x, который можно тут же запустить под WSL:
$ ./HelloHabr.x Hello, Habr! $ file HelloHabr.x HelloHabr.x: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, not stripped
Более того, вы можете собирать исполняемые файлы одновременно для Windows и Linux (равно как и 32- и 64-бит версии) сложив общий код во включаемый файл и пользуясь тем фактом, что в одном файле можно иметь множественные секции PROGRAM, единственная хитрость — нужно сбросить макросы между программами:
EUROASM AutoSegment=Yes, CPU=X64, SIMD=AVX2 HelloLinux PROGRAM Format=ELFX, Width=64, Entry=Start: INCLUDE linabi.htm, cpuext64.htm INCLUDE Code.asm ; < Your code ENDPROGRAM HelloLinux %DROPMACRO * ; Forget macros defined in "linabi.htm". HelloWindows PROGRAM Format=PE, Width=64, Entry=Start: INCLUDE winabi.htm, cpuext64.htm INCLUDE Code.asm ENDPROGRAM HelloWindows
Кстати, этот метод работает "в обе стороны", в том смысле, что вы можете не только собирать программы для Линукса из под Windows, но и наоборот из под Линукса под Windows, запуская euroasm.x.
Отладчик
Очень рекомендуется овладеть отладчиком. Можно использовать WinDbg, но многие предпочитают x64dbg, хотя он не без проблем (в смысле общей стабильности), но во многом удобнее.
Как им пользоваться? Допустим, вы не очень уверенно понимаете, как работает стек. Пишете небольшое приложение, которое заносит значения в два регистра, заталкивает их в стек, обнуляет (xor rax, rax — стандартный способ, привыкайте) и вытаскивает обратно:
EUROASM CPU=x64 %^SourceName PROGRAM Format=PE, Width=64, Entry=Start Start: nop mov rax, 0x17 mov rbx, 0x29 push rax, rbx xor rax, rax xor rbx, rbx pop rbx, rax jmp Start ENDPROGRAM
Запустите отладчик x64dbg (для отладки 32 бит приложения надо будет запускать 32-бит отладчик, у нас же 64 бита), затем откройте файл приложения (F3), после чего однократно нажмите F9 для загрузки и перемещения на точку входа, вы должны остановиться на NOP, затем пройдите пошагово, нажимая F7. Вот что вы увидите:
Хорошо видно, как уменьшается значение регистра RSP (указатель стека) на 8 байт при каждой инструкции push и как данные записываются в область памяти, на которую указывает указатель стека. Заметьте также, что ассемблер заменил инструкции mov rax, .. на mov eax, .., сэкономив вам несколько байт.
Ещё полезная вещь — листинг компиляции, который для примера выше выглядит вот так:
| |EUROASM CPU=x64 | |%^SourceName PROGRAM Format=PE, Width=64,... |[.text] ::::Section changed. |00000000: | |00000000:90 |Start: nop |00000001:B817000000 | mov rax, 0x17 |00000006:48BB2900000000000000 | mov rbx, 0x29, IMM=Q |00000010:5053 | push rax, rbx |00000012:4831C0 | xor rax, rax |00000015:4831DB | xor rbx, rbx |00000018:5B58 | pop rbx, rax |0000001A:EBE4 | jmp Start | |ENDPROGRAM | **** ListMap "StackTest.exe",model=FLAT,groups=0,segments=2,entry=Start | [.text],FA=0200h,VA=00401000h,size=28,width=64,align=0010h,purpose=CODE | [.rsrc],FA=0400h,VA=00402000h,size=13660,width=32,align=0010h,purpose=RES
Тут в левой колонке показаны машинные коды, в которые будут преобразованы инструкции. NOP — это машинный код 0х90 (который знает наизусть каждый реверс-инженер). Эти же машинные коды вы видите и в отладчике выше. Для примера я указал, что хочу получить именно 64-бит код для второго mov, добавив модификатор IMM=Q, и вы видите появившийся префикс 48 и 64 бит константу в восьми байтах. Вся архитектура фон Неймана раскрывается во всей красе.
Внизу вы видите виртуальный базовый адрес 00401000h (он складывается из стандартной базы 0х400000 и смещения), его же вы видите и в отладчике и секции файла, они выровнены на границу четырёх килобайт (0х1000), что составляет стандартный размер страницы памяти Windows. Всё просто.
Эксперимент — WinAPI
Вам никто не запрещает напрямую вызывать функции WinAPI прямо из Ассемблера, в 64-бит программе это делается следующим образом, для совсем тривиального примера два последовательных вызова GetTickCount64(), разделённых Sleep(1000):
EUROASM CPU=x64, SIMD=AVX2 %^SourceName PROGRAM Format=PE, Width=64, Entry=Start Elapsed D 32*B INCLUDE winabi.htm, cpuext64.htm Start: nop WinABI GetTickCount64 push rax WinABI Sleep, 1000 WinABI GetTickCount64 pop rbx sub rax, rbx StoD Elapsed StdOutput =B"Sleep(1000) - ", Elapsed, =B" ms", Eol=yes jmp Start ENDPROGRAM
Макрос WinABI следует соглашениям о вызове 64-бит функций — результат GetTickCount64() возвращается в RAX, параметр 1000 передаётся в Sleep() через RCX. Как результат вы будете видеть разницу в диапазоне 1000...1016 миллисекунд — так работает таймер низкого разрешения. В принципе ИИ способен достаточно внятно объяснить этот код выше.
Само собой, вы можете вызывать не только WinAPI, но и любые экспортированные функции из любой DLL, вот, к примеру, если рудиментарный вывод в консоль вас не устраивает, вы вполне можете воспользоваться стандартной printf(...) из msvcrt.dll:
EUROASM CPU=X64, SIMD=AVX2 printf1 PROGRAM Format=PE, Width=64, Model=Flat, Entry=main: INCLUDE winabi.htm LINK msvcrt.lib ; for printf(...) main: nop mov rax, 42 WinABI printf, =B"printf: The Answer is %%d", rax ENDPROGRAM
При этом поддерживается и динамический вызов при отсутствии *.lib файла, так тоже можно:
EUROASM CPU=X64, SIMD=AVX2 printf2 PROGRAM Format=PE, Width=64, Model=Flat, Entry=main: INCLUDE winabi.htm main: nop mov rax, 42 WinABI printf, =B"printf: The Answer is %%d", rax, Lib=msvcrt.dll ENDPROGRAM
И поскольку евроассемблер — это и ассемблер и линковщик "в одном флаконе", то существует удобный скрипт, генерирующий библиотеку импорта lib из динамической библиотеки — dll2lib.htm.
Вообще использовать ассемблер для микробенчмаркинга очень хорошо, поскольку всё находится в ваших руках, позволяя спуститься на уровень машинного кода, но, конечно же не при помощи GetTickCount. Ниже ещё пара примеров. Обычно в этом месте дотошные читатели резонно замечают, мол всё тоже самое можно получить на Си/С++ заметно меньшими усилиями, и это в общем так, но в данном случае мы не зависим от компилятора, его версии и опций оптимизатора, и всё под контролем. Ниже ещё несколько примеров на ассемблере, они не настолько велики, чтобы ради них писать отдельные статьи, но в контексте изложения — вполне уместны.
Эксперимент — работа предсказателя переходов
Не так давно на хабре была статья Ловушка профилирования, где были получены довольно любопытные результаты. Суть там была в том, что используя google benchmark производились замеры времени исполнения кода с переходами и эквивалентного кода без них, и внезапно выяснилось, что результат зависим не только от кода, но и от данных, которые используются — при проходе по одному и тому же массиву результаты улучшались, а при изменении данных от прогона к прогону — ухудшались. Вот как можно провести поверку результатов на ассемблере.
Для начала нам понадобится пара нехитрых макросов, которыми мы будем обкладывать наш код, время выполнения которого мы хотим измерить и макрос, который выведет результат. Предполагается, что мы вызовем код много раз в цикле и возьмём минимальное время прохода — это стандартный способ для синтетического бенчмаркинга:
Buffer DB 80 * B StartBench %MACRO CPUID RDTSC shl rdx, 32 or rax, rdx mov r8, rax %ENDMACRO EndBench %MACRO Min RDTSCP shl rdx, 32 or rax, rdx sub rax, r8 mov rbx, [%Min] cmp rax, rbx cmova rax, rbx mov [%Min], rax %ENDMACRO PrintBench %MACRO Message, Min mov rax, [%Min] StoD Buffer StdOutput =B%Message, Buffer, =B" Ticks", Eol=Yes, Console=Yes Clear Buffer, Size=80 mov [%Min], -1, DATA=Q %ENDMACRO
Здесь используется инструкция RDTSC для получения тиков тактового генератора, работающего на базовой частоте процессора. Пара CPUID/RDTSC...RDTSCP — это классический подход для того чтобы свести к минимум влияние конвейеризации на результаты. Значение при старте сохраняется в R8. Затем в конце сравнивается с минимальным значением, которое обновляется. Обратите внимание на инструкцию cmova — это стандартный способ избавиться от явного перехода if (value<min) min = value; а сравниваем мы беззнаковые числа.
Ещё нам понадобится генератор случайных чисел, который заполнит массив Array размером %SIZE случайными байтами 0 или 1. Этот код, кстати, генерированный ИИ копилотом чуть более чем полностью и в общем живой и рабочий, при этом количество вызовов rdrand минимально — мы берём оттуда одиночные биты, так что один вызов поставляет нам 64 случайных числа, я оставлю оригинальные комментарии как есть:
random PROC mov rdi, Array mov rcx, %SIZE xor rdx, rdx .next_byte: test rcx, rcx jz .done ; finished ; if no bits left in rbx, get a new 64-bit random value test rdx, rdx jnz .have_bits .get_rdrand: rdrand rbx ; random 64-bit value in rbx jnc .get_rdrand ; retry if CF=0 (no random value) mov rdx, 64 ; 64 bits available .have_bits: ; take lowest bit of rbx, store it as a byte 0 or 1 mov al, bl ; copy low byte and al, 1 ; keep only lowest bit (0 or 1) mov [rdi], al ; store into buffer shr rbx, 1 ; drop used bit dec rdx ; one less available bit inc rdi ; advance buffer pointer dec rcx ; one less byte to fill jmp .next_byte .done: ret ENDPROC random
Вот, почти всё готово, теперь мы напишем небольшой тест, который запустим десять тысяч раз, меняя содержимое массива на каждом проходе вызовом call random:
EUROASM CPU=X64, SIMD=AVX2, SPEC=Enabled %^SourceName PROGRAM Format=PE, Width=64, Model=Flat, Entry=main %SIZE %SET 4096 %ITER %SET 10000 INCLUDE winscon.htm, winabi.htm, cpuext64.htm INCLUDE Benchmark.inc, Random.inc Array: DB %SIZE * BYTE ; 4 KiB Buffer RCycl DB Q -1 NCycl DB Q -1 main:nop StdOutput =B"Branch prediction benchmark", Eol=yes ;----------------------------------------------------------------------------- ; First Test - random array every time mov r10, %ITER ; number of timing iterations loop: call random StartBench mov r11, %SIZE ; loop counter N lea r12, [Array] ; r12 = address of byte array xor r13, r13 ; r13 = taken-branch counter (per timing run) loop_start: mov bl, [r12] ; load current value (0 or 1) test bl, bl jz branch ; branch-taken path inc r13 ; do some harmless work branch: ; no work for 0, but still advance inc r12 ; next byte dec r11 jne loop_start EndBench RCycl dec r10 jnz loop PrintBench "Rand Array: ", RCycl
В регистре R13 у нас будет количество переходов, при случайном массиве размеров 4К должно быть что-то около двух тысяч, это просто для самоконтроля.
Ну а второй тест мы будем запускать по одному и тому же массиву:
;----------------------------------------------------------------------------- ; Second Test - same array every time mov r10, %ITER loop2: StartBench mov r11, %SIZE lea r12, [Array] xor r13, r13 loop_start2: mov bl, [r12] test bl, bl jz branch2 inc r13 branch2: inc r12 dec r11 jne loop_start2 EndBench NCycl dec r10 jnz loop2 PrintBench "Same Array: ", NCycl TerminateProgram ENDPROGRAM
И вот результат на процессоре Хасвелл:
Branch prediction benchmark
Rand Array: 51960 Ticks
Same Array: 36524 Ticks
Как видите, в первом случае процессору потребовалось в полтора раза больше времени, так работает постоянно ошибающийся предсказатель переходов. Он на самом деле многоуровневый и может "удержать" в памяти до 4К последних переходов. Я изначально полагал, что основное влияние оказывает кэш, но нет, это именно эффект предсказателя. Можно воспользоваться профилировщиком VTune либо Intel PCM и убедиться, что количество промахов предсказателя значительно выше в первом случае. Это на самом деле неплохой результат для цикла, в котором семь инструкций, отрабатывающего 4 тысячи итераций. В качестве самостоятельного упражнения попробуйте оставить массив, забитый нулями (да просто закомментируйте вызов call random добавив перед этой строкой ";") и вы увидите, как количество тиков упадёт где-то до восьми тысяч — это всего два такта на итерацию. Так работает конвейер вкупе с предсказателем, всегда верно угадывающим переход — ведь современный процессор может выполнять несколько инструкций, таких как комбинации dec/jne и dec/jnz при верно предсказанном переходе за один такт.
Эксперимент — сравнение INC и ADD
Ещё один эксперимент, основанный на статье Может ли устареть инкремент....
Значение регистра процессора можно инкрементировать двумя способами — либо как inc rax, либо add rax, 1. Есть ли разница между этими командами? Небольшой эксперимент на ассемблере поможет ответить и на этот вопрос. Кроме того в рамках этого эксперимента мы может воочию увидеть латентность и пропускную способность инструкций. Замеры мы будем проводить двумя способами — в одном случае мы будем просить выполнить инкремент одного и того же регистра, это даст нам зависимость по данным, а во втором случае — независимых регистров, и в этом случае процессор может начать их параллельное выполнение соответственно пропускной способности. Значения латентности и пропускной способности можно проверить в таблицах uops.info.
Чтобы выдать последовательность одних и тех же команд без утомительного копипастинга , мы воспользуемся макро языком ассемблера. Основная управляющая конструкция выглядит вот так:
i %FOR 0..10000 inc eax %ENDFOR i
Здесь будет выдано десять тысяч последовательных команд inc eax, одна за одной. Если бы мы использовали нативный цикл ассемблера, то счётчик цикла "сбил" бы нам результат измерений, его пришлось бы учитывать, а в данном случае у нас именно непрерывная последовательность. Она не должна быть очень большой, желательно, чтобы мы полностью поместились в кэш инструкций, но и не маленькой, чтобы эффект был хорошо заметен.
Теперь важно понять следующее. Когда мы выдаём команды inc eax, inc eax, ... одну за одной — они зависимы по данным, это значит, что процессор должен формально дождаться выполнения предыдущей инструкции, чтобы начать следующую (хотя и не всегда — это зависит от архитектуры). Количество тактов, затрачиваемое на одну такую инструкцию — это латентность. Однако если наши инструкции будут независимы, то процессор может начать выполнение следующей, не дожидаясь предыдущую, и количество таких инструкций, выполняемых за один такт — это пропускная способность. Последовательность из десяти тысяч независимых инструкций создаётся вот так:
i %FOR 0..2500 inc rax inc rbx inc rcx inc rdx %ENDFOR i
Здесь у нас 2500 раз повторённая последовательность из четырёх команд, всё вместе — 10000.
Кстати, в этом ассемблере вы можете комбинировать множественные инкременты, то есть код "inc rax, rbx, rcx, rdx" - это ровно тоже самое, что и четыре отдельных инкремента выше.
Полный код под спойлером
EUROASM AutoSegment=Yes, CPU=X64, SIMD=AVX2 %^SourceName PROGRAM Format=PE, Width=64, Model=Flat, IconFile=, Entry=main: %ITER %SET 250_000 INCLUDE winscon.htm, winabi.htm, cpuext64.htm INCLUDE benchmark.inc Cycles DB Q -1 main: nop mov r9, %ITER L1: ; --- Latency for ADD Instruction StartBench i %FOR 0..10000 add eax, 1 %ENDFOR i EndBench Cycles dec r9 jnz L1 PrintBench "ADD cycles (Latency) = ", Cycles mov r9, %ITER L2: ; --- Latency for INC Instruction StartBench i %FOR 0..10000 inc eax %ENDFOR EndBench Cycles dec r9 jnz L2 PrintBench "INC cycles (Latency) = ", Cycles mov r9, %ITER L3: ; --- Throughput for ADD Instruction StartBench i %FOR 0..2500 add rax, 1 add rbx, 1 add rcx, 1 add rdx, 1 %ENDFOR i EndBench Cycles dec r9 jnz L3 PrintBench "ADD cycles (Throughput) = ", Cycles mov r9, %ITER L4: ; --- Throughput for INC Instruction StartBench i %FOR 0..2500 inc rax, rbx, rcx, rdx %ENDFOR i EndBench Cycles dec r9 jnz L4 PrintBench "INC cycles (Throughput) = ", Cycles TerminateProgram ENDPROGRAM
И вот результат для процессора Xeon E5-1620 v3 (Haswell):
>AddInc.exe ADD cycles (Latency) = 10028 Ticks INC cycles (Latency) = 10028 Ticks ADD cycles (Throughput) = 3376 Ticks INC cycles (Throughput) = 3364 Ticks
Всё красиво — для 10000 зависимых инструкций процессору надо примерно 10000 тиков, это ровно одна инструкция на такт, а вот для независимых инструкций — втрое меньше, потому что он начинает выполнять три инструкции за каждый такт. И нет, разницы между INC и ADD ровно никакой. Единственное отличие в длине машинного кода, ведь add eax, 1 это три байта 83C001, а вот inc eax — только два FFC0. Более компактный код занимает меньше места в кэше инструкций и в общем предпочтительнее.
Ситуация, кстати, поменяется, если погонять этот код на P и E ядрах гибридного процессора, например на Core i7-13850HX, вот там ADD инструкция окажется предпочтительнее на Е ядрах, но это уже совсем другая история. Я не буду показывать результаты, поскольку здесь придётся объяснять, что RDTSC на самом деле показывает количество тиков на базовой частоте процессора, а он как правило работает на повышенной частоте и в реальности количество тактов на данном процессоре окажется заметно выше, кроме того придётся делать поправку на разную частоту ядер и лучше использовать RDPMC, но там есть свои тонкости, о которых я писал в статье Достучаться до RDPMC, но вот про исключение, которое можно спровоцировать этой инструкцией, хотелось бы написать особо.
Эксперимент — обработка исключений
Вообще при программировании на Ассемблере не бойтесь исключений вам прилетающих. Здесь вы с процессором "один на один" и можете легко отправить его в нокдаун. На выброшенные исключения натыкался каждый программист, и каждый, работающий с С++ в курсе про __try... __except, но мой беглый опрос коллег показал, что не каждый точно знает, как именно исключение обрабатывается, и вот тут ассемблер может помочь разобраться (или, напротив, запутать, тут уж кому как).
Мы не будем искать простых путей. Запись по нулевому указателю, равно как и деление на нуль — это слишком уж просто, там можно избежать исключения банальной проверкой. Давайте возьмём пример посложнее, когда шансов нет — мы попросим процессор выполнить привилегированную инструкцию не имея на это соответствующего разрешения. Выше упоминалась RDPMC, которая как раз таковой и является.
Вот вам наипростейшая программа на ассемблере:
EUROASM CPU=x64 %^SourceName PROGRAM Format=PE, Width=64, Entry=Start INCLUDE winabi.htm Start: nop StdOutput =B"Before RDPMC Call", Eol=yes xor ecx, ecx RDPMC ; Exception! StdOutput =B"After RDPMC Call", Eol=yes TerminateProgram ENDPROGRAM
При запуске вы увидите первое сообщение, но не увидите второго, потому что в просмотрщике событий вы увидите ошибку с кодом 0хс0000096:
(тысяча извинений за немецкий скриншот, но тут всё понятно). Это документированная ошибка STATUS_PRIVILEGED_INSTRUCTION.
Ровно того же эффекта вы добьётесь если попробуете на С++ __readpmc():
#include <iostream> #include <windows.h> int main() { // This will fault unless RDPMC is enabled for user mode std::cout << "Before RDPMC call" << std::endl; uint64_t value = __readpmc(0); std::cout << "RDPMC value: " << value << std::endl; return 0; }
Однако не всё так плохо, ведь вы можете сделать вот так:
#include <iostream> #include <windows.h> int main() { std::cout << "Before RDPMC call" << std::endl; __try { // This will fault unless RDPMC is enabled for user mode uint64_t value = __readpmc(0); std::cout << "RDPMC value: " << value << std::endl; } __except (EXCEPTION_EXECUTE_HANDLER) { std::cout << "SEH caught RDPMC exception!" << std::endl; } return 0; }
И в этом случае программа не упадёт, она честно выдаст SEH caught RDPMC exception!
И вот тут если вы попросите объяснить, как именно производится структурированная обработка исключений, то многие затруднятся ответить, а на самом деле там всё относительно несложно.
Вот эквивалентный код на ассемблере, заодно и протестируем адекватность кнопки "объяснить код":
EUROASM CPU=X64, SIMD=AVX2 %^SourceName PROGRAM Format=PE, Width=64, Model=Flat, IconFile=, Entry=Start INCLUDE winscon.htm, winabi.htm, cpuext64.htm [.text] Start: nop StdOutput =B"Hello, SEH", Eol=yes try: MOV ECX,0 ; Instructions Retired RDPMC ; EXCEPTION_PRIV_INSTRUCTION (0xC0000096) safe_place: StdOutput =B"Sucessfully finished", Eol=yes TerminateProgram handler: SUB RSP,8*(4+1) ; 0x0F8 is offset to CONTEXT64.Rip: mov [R8+0x0F8], safe_place, DATA=Q StdOutput =B"Instruction caused exception", Eol=yes XOR EAX,EAX ADD RSP,8*(4+1) retn [.data] align 4 ; alignment is required UNWIND DB 0x19,0,0,0 ; Hard coded for the moment DD RVA# handler DD 0 [.pdata] SEGMENT PURPOSE=EXCEPTION DD RVA# try DD RVA# safe_place DD RVA# UNWIND ENDPROGRAM
Здесь есть три важных адреса: try — это то место, где может поплохеть, затем safe_place: — это там, где снова станет хорошо, и handler:, которое суть обработчик.
Чтобы сообщить операционной системе о том, как мы собираемся обрабатывать ошибку, служит секция [.pdata], туда занесены три адреса (по сути это RUNTIME_FUNCTION структура) — собственно критическое место и безопасное продолжение, а также адрес UNWIND_INFO структуры. Магическое число 0х19 образуется из трёх битов, где один отвечает за версию, а другие два говорят о том, что у нас есть есть SEH‑обработчик UNW_FLAG_EHANDLER с пользовательским обработчиком UNW_FLAG_UHANDLER. Следом идёт относительный адрес обработчика (тут все адреса относительные, поэтому RVA, это как раз добавилось в свежей версии этого ассемблера). Теперь, когда мы налетаем на грабли инструкцией RDPMC, ядро операционной системы первым делом просматривает таблицу обработчиков, если её нет, то программа аварийно завершается, а вот если есть, управление передаётся нашему обработчику handler:. Но это не просто передача управления, по сути под капотом идёт вызов функции с четырьмя параметрами, которые передаются согласно соглашению о вызовах Win64 ABI. Вот почему нам первой же командой нужно выравнивание стека на 4 параметра плюс один — это адрес возврата (можно и SUB RSP, 48 сделать, хуже не будет). Четыре параметра, которые нам передаются, берутся из вот такого прототипа
typedef EXCEPTION_DISPOSITION (*PEXCEPTION_ROUTINE) ( IN PEXCEPTION_RECORD ExceptionRecord, IN ULONG64 EstablisherFrame, IN OUT PCONTEXT ContextRecord, IN OUT PDISPATCHER_CONTEXT DispatcherContext );
Соответственно они передаются через регистры RCX, RDX, R8 и R9. Из всего этого нас интересует лишь структура PCONTEXT ContextRecord, адрес который лежит в R8, так как это третий параметр. Смещение 248 байт 0x0F8 — это поле RIP. А RIP это указатель адреса текущей инструкции. Именно сюда мы записываем адрес безопасного продолжения safe_place. Больше от нас ничего не требуется, мы выводим сообщение, что нас настигло исключение, сбрасываем код ошибки и восстанавливаем стек обратно. По выходу из процедуры обработчика исключения ядро выставит наш желаемый "безопасный" RIP, и мы выведем последнее сообщение. Вот и всё. На самом деле можно усложнить — например получить код исключения, и т.д.
Это как раз тот пример, когда ассемблер помогает понять механизм работы.
На этом можно было бы остановиться, но хотелось бы добавить, что код на ассемблере можно собрать и в DLL, которую вызвать из любого языка, который это допускает, начиная от Си и Питона и заканчивая Растом и LabVIEW, что открывает возможности для практического применения ассемблерного кода и интегрирования его в сторонние приложения.
DLL на ассемблере
Чтобы не усложнять, давайте просто сложим пару байтовых массивов, но используя SIMD инструкции, и вызовем полученную библиотеку, скажем из LabVIEW. Помимо очевидной замены РЕ на DLL нам потребуется занести нашу функцию в таблицу экспорта, ну и конечно же назубок выучить соглашение о передаче параметров. Собственно и всё:
EUROASM CPU=X64, SIMD=AVX2, AMD=ENABLED AsmDLL64 PROGRAM FORMAT=DLL, MODEL=FLAT, WIDTH=64 EXPORT add_bytes_avx2 ; void add_bytes_avx2(const uint8_t* a, ; const uint8_t* b, ; uint8_t* c, ; size_t n); add_bytes_avx2 PROC test r9, r9 jz done ; number of full 32-byte blocks mov r10, r9 shr r10, 5 ; r10 = n / 32 jz tail avx_loop: vmovdqu ymm0, [rcx] vmovdqu ymm1, [rdx] vpaddb ymm0, ymm0, ymm1 vmovdqu [r8], ymm0 add rcx, 32 add rdx, 32 add r8, 32 dec r10 jnz avx_loop tail: ; remaining bytes and r9, 31 jz done tail_loop: mov al, [rcx] add al, [rdx] mov [r8], al inc rcx, rdx, r8 dec r9 jnz tail_loop done: vzeroupper ; important for ABI ret ENDP add_bytes_avx2 ENDPROGRAM AsmDLL64
И результат:
Очевидно, что эту же функцию можно вызвать откуда угодно.
Литература
Из чис��а более-менее современных книг можно порекомендовать Modern X86 Assembly Language Programming: Covers X86 64-bit, AVX, AVX2, and AVX-512:
Автор — Даниэль Куссвюрм. Второе издание было переведено на русский под названием "Профессиональное программирование на ассемблере x64 с расширениями AVX, AVX2 и AVX-512".
Код к этой книге выложен на гитхаб и вполне переносим на данный ассемблер. Также можно порекомендовать титанические заметки по оптимизации Агнера Фога и Performance Analysis and Tuning on Modern CPUs Дениса Бахвалова. В принципе этих материалов уже достаточно для начала увлекательного путешествия, и я хочу пожелать всем удачи на этом тернистом пути.
