Поревьюим и порефакторим — Ассемблер для любопытных #213.11.2024 07:16

Ещё статья про ассемблер для тех кто с ним не знаком. В предыдущей про 5 ассемблеров последний примерчик вызвал критику за «упрощенизм». Давайте посмотрим вместе как его улучшить и немножко нарастить — в качестве «продолжения знакомства».

Заодно полюбуемся на несовместимость Linux и BSD, а также на различие 32 и 64-битной версии обеих ОС — и подумаем как с этим бороться.

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

План нашего повествования

  1. Вспомним пример с «Hello World» на ассемблере под линукс, напомним что там к чему — регистры, системные вызовы и т.п.

  2. Макросы — научимся «абстрагировать» фрагменты кода с их помощью

  3. Подпрограммы — аналоги функций и процедур

  4. Реальная задачка — добавим функцию определения длины строки

  5. Результат рефакторинга — окинем взглядом что получилось

  6. Поговорим о функциях чтении строки и печати целого числа (упражнение)

  7. Стек — его мы до сих пор не касались, а вещь краеугольная

  8. Как меняются системные вызовы в зависимости от ОС и разрядности (боль) — бегло обсудим возможности создания «более переносимого» кода

Пример с которого всё началось

Мы говорили об ассемблерах для разных процессоров — смотрели на сходства и различия, чтобы немножко освоиться в теме — и какие-то подробности про разные платформы узнать. И последним шёл вариант с использованием ассемблера на нашем популярном x86 / amd64 «железе» — в виде «Hello World» под Linux. Как мы разобрались — там делов всего лишь — вызвать системную функцию (из самого ядра) — подготовив ей нужные параметры.

Вот этот код — сейчас мы немножко освежим воспоминания о нём и перейдём к улучшениям: 

.section .data
msg: .ascii "Hi, Peoplez!\n"
len = . - msg

.section .text
.global _start

_start:
mov $4, %eax
mov $1, %ebx
mov $msg, %ecx
mov $len, %edx
int $0x80

mov $1, %eax
mov $0, %ebx
int $0x80

Это 32-битная версия — она без проблем соберется и запустится и на 64-битном линуксе. Про 64-битную версию тоже поговорим ниже -, но очевидно её на 32-битной машине вы запустить не сможете.

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

ca6aea8c9c46d798433f413fdc565b16.png

первая строчка — вызов ассемблера, вторая — линкера, ну, а в третьей мы вызываем скомпилированную программу. Если вы захотите собственными руками потренироваться с этим и последующими примерами — используйте любой линукс с gcc (если живёте на win — сгодится загрузочный диск или флешка — или их образ для виртуалки). Если всё это вас не устраивает — напишите, добавлю возможность компилировать и выполнять ассемблерный код у себя на сайте (вот забава будет задачки на нем решать).

Как это работает

Напомню, EAX, EBX, ECX, EDX — регистры процессора, его ячейки памяти которые можно использовать для всевозможных временных переменных. Команда MOV это присваивание — числа в регистр или значения из одного регистра в другой, например — очевидно от слова «move» — хотя правильнее сказать что мы не «передвигаем» значение, а копируем его. Ну исторически сложилось.

Первые строчки посвящены объявлению секции с данными — здесь мы размещаем текстовую строчку и отмечаем её адрес меткой msg: — далее следует секция с кодом (text) и вот здесь происходит главное, после метки _start:.

Команта int 0x80 вызывает «вручную» прерывание (interrupt) с указанным номером — и на этом номере сидят системные функции ядра ОС. Функций много, и нужная определяется тем, какое число оказалось загружено в регистр EAX — поэтому немного ранее мы записали туда 4, что соответствует функции write. Она принимает три параметра в трех следующих регистрах:

  • куда записать — в EBX номер «потока» ввода-вывода, в данном случае 1 означает stdout, вывод в консоль

  • с какого адреса брать данные — в ECX указан адрес с помощью метки msg

  • сколько байт записать — в EDX записывается автоматически посчитанная компилятором константа len (мы её потом уберем, поэтому не будем углубляться)

После того как строчка напечатана, следующим этапом мы снова «дёргаем ядро» -, но теперь уже с функцией EAX=1 — это просто exit — завершение программы. В EBX передаётся код возврата (ноль — значит, без ошибки). Почему нужен exit? да ведь завершение программы это сложная операция — высвобождается поток и так далее — всё это не происходит «само собой» просто по достижении последней инструкции. Без системного вызова процессор просто побежит дальше, пытаясь исполнять случайные байты встреченные на пути в памяти программ.

В общем, вот это безобразие мы сейчас попробуем улучшить :)

Первые улучшения — макросы

Например вот это int 0x80 — хотя подобное ностальгически мило многим кто знаком с x86 ассемблером, но оставлять так нехорошо. И опечататься можно, и смысловая нагрузка непонятна. А главное — в 64-битном линуксе вместо этого используется специальная инструкция syscall. Вот захотим на более современную архитектуру перейти — и придётся по коду заменять одну команду на другую — нехорошо!

Практически все ассемблеры позволяют макроопределения, например вот так: 

.macro sys_call
int $0x80
.endm

Мы определим словечко sys_call и будем вписывать его, а не саму команду. Потом можно будет команду заменить в одном месте.

Некоторые ассемблеры (и GNU в том числе) позволяют добавлять параметры к макроопределениям, например можно номер требуемой функции задать параметром. И сами номера переопределить константами компилятора: 

.equ fn_write, 4
.equ fn_exit, 1

.macro sys_call fn
mov \fn, %eax
int $0x80
.endm

; ...

_start:
mov $1, %ebx
mov $msg, %ecx
mov $len, %edx
sys_call $fn_write

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

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

Подпрограммы (aka процедуры или функции)

Нам было бы удобно назвать первую «часть» как-нибудь print_str и передавать ей только один параметр — адрес строки. Что делать с остальными двумя? Номер «потока» можно захардкодить, если считать что выводим всегда в консоль. А как быть с длиной? Давайте посмотрим на вот такую «заготовку» из двух функций: 

# ECX - string address
print_str:
  mov $1, %ebx
  call str_len
  mov %eax, %edx
  sys_call $fn_write
  ret

# ECX - string address
# returns length in EAX
str_len:
  ; ...
  ret

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

В первой подпрограмме мы сделаем системный вызов для записи строки, но перед этим как и раньше занесем EBX=1, адрес же строки должен быть передан в саму функцию в ECX, а длину мы вычислим в отдельной подпрограмме, которую ещё предстоит написать. Результат из подпрограмм принято возвращать через регистр EAX, хотя нужен он в EDX — поэтому сделаем дополнительный MOV между ними. Кажется что это заведомая маленькая «неэффективность», но программы на ассемблере маленькие и быстрые так что мы обычно не смущаемся добавлять где-то лишние команды лишь бы было удобнее пользоваться.

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

Но как же будет работать функция определения длины строки?

Функция определения длины строки

Давайте использовать строки с нулём в конце, как в Си. Тогда подпрограмма str_len сможет посчитать длину пробежавшись в цикле пока не встретит этот самый 0.

В общих чертах понятно. А как это сделать в подробностях? Давайте скопируем адрес строки в EAX и будем в цикле увеличивать его, пока не обнаружим что он указывает на байт со значением 0. После этого достаточно вычесть из него исходный адрес строки (он так и остался в ECX: 

str_len:
  mov %ecx, %eax
strlen_next:
  cmpb $0, (%eax)
  jz  strlen_done
  inc %eax
  jmp strlen_next
strlen_done:
  sub %ecx, %eax
  ret

В начале, как сказано выше, копируем адрес в EAX. Дальше идёт тело цикла, начиная с метки strlen_next — следом идёт команда CMP — она сравнивает два аргумента (на самом деле вычитает первый из второго, но результат никуда не записывает). В результате её устанавливаются арифметические флаги, в частности флаг нуля Z если операнды были равны (т.е. в результате вычитания получился 0).

И вот этот флаг мы проверяем командой JZ (jump if zero) — если нашли 0, то перепрыгнем на указанную метку strlen_done. Если нет — просто идём дальше.

А дальше у нас увеличение EAX с помощью команды INC (increment) — и безусловный переход JMP к началу цикла.

Когда выйдем из цикла, после метки strlen_done останется только вычесть начальный адрес из регистра EAX — это делается командой SUB (subtract). И всё — результат (длина строки) — в регистре EAX.

Это очень короткий код, но он потребовал некоторых умственных усилий. Давайте «причешем» программу и посмотрим как теперь это выглядит целиком.

Результат рефакторинга

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

.equ fn_write, 4
.equ fn_exit, 1

.macro sys_call fn
mov \fn, %eax
int $0x80
.endm

.section .data
msg: .ascii "Hi, Peoplez!!!\n\0"

.section .text
.global _start

#===========================
_start:
  mov $msg, %ecx
  call print_str
  call normal_exit

#===========================
# no input arguments
normal_exit:
  mov $0, %ebx
  sys_call $fn_exit

#===========================
# address of string in ECX
print_str:
  call str_len
  mov %eax, %edx
  mov $1, %ebx
  sys_call $fn_write
  ret

#===========================
# address of string in ECX
# returns length in EAX
str_len:      # string in ecx
  mov %ecx, %eax
strlen_next:
  cmpb $0, (%eax)
  jz  strlen_done
  inc %eax
  jmp strlen_next
strlen_done:
  sub %ecx, %eax
  ret

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

Чтение строчки и вывод целого числа

В примере программы, который использован в статье про «Голый Линукс» чуть более сложный функционал — мы не только печатаем приветственную строку, но и:

  • ждём ввода строки текста от пользователя

  • печатаем длину введённой строки

  • повторяем все это в цикле

Из этого функционала маленький кусочек у нас уже есть — функция определения длины строки. А что с остальными? Мне не хочется усугублять данную статью лишним кодом, поэтому предлагаю так — ниже будет краткое описание и кому любопытно — тот попробует разобраться с кодом (или написать похожий) — если будет много пожеланий, давайте вынесем это в отдельную статью (а кому неинтересно — с теми перейдём дальше к вопросам переносимости и совместимости).

Итак для ввода строки используется другая системная функция (#3) — чтение из канала ввода. Ей тоже передаётся номер канала (0 — stdin) — и сколько байт прочитать. Здесь есть загвоздка — мы не знаем сколько пользователь введет и хотим читать до конца строки. Поэтому будем читать по 1 байту (сдвигая указатель перед каждым вызовом) пока не введен символ возврата строки — после этого допишем в строку нулевой байт как признак конца. Всё это оформлено в подпрограмму gets. Проверки на максимальную длину буфера в ней нет (можете добавить конечно).

Длину посчитать мы можем -, а теперь нужно превратить её в число в строковом представлении. Принцип известен — делим на 10, берем остатки (и добавляем к ним ASCII-код нуля) — однако строчка получится задом-наперед, так что ещё надо будет её развернуть. Можно действовать и иначе, пофантазируйте. Эта подпрограмма зовётся itoa.

Код в примере не очень аккуратный, так что не стесняйтесь применить к нему свои познания в рефакторинге:)

Зато главная программа выглядит компактно и довольно понятно — тут только вызовы подпрограмм и передача им то буфера то строчки в качестве параметра: 

_start:
    movl $msg, %ecx
    call puts
again:
    movl $strbuf, %ecx
    call gets
    call strlen
    movl $strbuf, %ecx
    call itoa
    movl $strbuf, %ecx
    call puts
    movl $nl, %ecx
    call puts
    jmp again

Стек, SP, PUSH, POP

Маленькая, но важная вещь о которой мы до сих пор умалчивали — стек процессора. Это удобная фича многих процессоров — есть команды PUSH и POP — первая из них позволяет сохранить значение регистра на стеке -, а вторая наоборот выталкивает из стека и записывает в регистр. Например это очень удобно при входе в подпрограмму — все регистры значения которых будут «повреждены» — можно временно затолкать в стек (а при выходе восстановить оттуда, в обратном порядке).

Где этот «стек» хранится физически — в большинстве случаев это просто область памяти на которую указывает специальный регистр SP (он же ESP или RSP в зависимости от разрядности процессора) — от слова stack pointer. Но не всегда. Например в младших AVR бывает встроенный хардварный стек — в него никакими другими средствами не залезешь.

Кстати и сам вызов подпрограммы обычно (не в любой архитектуре однако!) делается с помощью стека: команда CALL заталкивает адрес следующей за ней команды в стек, а потом делает прыжок (такой же как JMP) на нужную метку. Команта возврата RET выталкивает адрес из стека и делает прыжок на полученное значение. Именно этот механизм обеспечивает возможность рекурсивного вызова функций между прочим.

Почему мы сейчас решили про стек рассказать? Как вы увидите, он используется для системных вызовов в альтернативных ОС.

Системные вызовы в Linux-64 и FreeBSD

Мы до сих пор пользовались системными вызовами в стиле 32-битного Linux. Теперь посмотрим что изменилось в «родственных» системах — рассмотрим 64-битную FreeBSD, далее 64-битный Linux и наконец вернёмся в 32-бита на FreeBSD. Именно в таком порядке — чтобы легче воспринять разницу осуществления системных вызовов.

10680a574cd389df1f6863233cc9b0fd.png

Из общих сведений обратим внимание на то что в 64-битных системах мы обычно используем 64-битные регистры с префиксом R (rax, rbx… вместо eax, ebx) — причем прежде виденные 32-битные регистры являются частью 64-битных (т.е. eax это младшая половина rax и так далее).

Итак, FreeBSD 64 bit

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

  • раньше мы видели EAX — номер функции, EBX, ECX, EDX — первый, второй, третий параметры для передачи в эту функцию (этот порядок отчасти напоминает MS-DOS)

  • теперь хотя остаётся RAX — номер функции, аргументы идут по порядку в RDI, RSI, RDX, RCX… (мы ещё не встречали регистры xDI, xSI -, но в целом они ведут себя как и остальные)

Кроме того сам системный вызов теперь делается специальной инструкцией syscall вместо морально устаревшего int 0x80 —

Если мы модифицируем предложенную выше программу, получится (не включая str_len) достаточно похожий код: 

...

.macro sys_call fn
mov \fn, %rax
syscall
.endm

...

#===========================
_start:
  mov $msg, %rsi
  call print_str
  call normal_exit

#===========================
# no input arguments
normal_exit:
  mov $0, %rdi
  sys_call $fn_exit

#===========================
# address of string in RSI
print_str:
  call str_len
  mov %rax, %rdx
  mov $1, %rdi
  sys_call $fn_write
  ret

...

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

Можно добавить эти аргументы к самому макросу, как-то так: 

.macro sys_call fn arg1=0 arg2=0 arg3=0 arg4=0
mov \fn, %rax
mov \arg1, %rdi
mov \arg2, %rsi
mov \arg3, %rdx
mov \arg4, %rcx
syscall
.endm

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

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

К сожалению с функцией str_len ещё придётся колдовать — сам по себе её код точно также будет работать на 64-битной системе, т.к. он использует валидные регистры -, но для того чтобы передать в неё параметры и получить результат в «совместимом» виде — понадобится что-то придумать.

Однако не будем на этом задерживаться и пойдём дальше.

Linux 64 бит

По сравнению с FreeBSD 64 бит тут всё похоже — те же «обновлённые» регистры, тот же порядок (в отличие от старого 32-битного Linux) и тот же syscall.

Но есть и отличие — номера системных вызовов поменялись. Они их все перепутали, Карл!!!

Теперь функция write будет не 4, а 1. Функция exit же была 1, а стала 60. Надеюсь вам понятна логика? (мне нет)

В остальном код будет идентичен варианту FreeBSD 64, то есть написать переносимую программу для этих двух случаев проще всего — просто вынесем строчки с определением номеров системных функций в отдельный подключаемый файл: 

.equ fn_write, 1
.equ fn_exit, 60

То есть достаточно завести linux64.inc и freebsd64.inc с разными номерами функций — и включать тот либо другой. Альтернативный вариант — можно использовать сишный препроцессор с #define ... #if ... #else ... #endif — Gnu ассемблер использует его автоматически если расширение файла указать большой буквой .S

Отметим однако что сами по себе системные функции могут немного различаться. Те которые существовали исторически ещё в Unix будут идентичны почти наверняка -, но более поздние различаются. Даже их количество неодинаково (во FreeBSD их 500 с хвостиком, в Линуксе по-моему ощутимо меньше).

FreeBSD 32 бит

Возвращаясь в 32-битную FreeBSD мы обнаруживаем что номера функций используются старые (в общем, они везде одинаковы кроме Linux-64) — и используется старый добрый вызов int 0x80.

Но значительное различие в том как передаются параметры. Они вообще передаются не в регистрах, а на стеке — это Си-шный (и Юниксовый исторически) стиль. То есть если взять самый первый пример, его пришлось бы написать вот так: 

...
push $len
push $msg
push $1
push $4
int $0x80
add $16, %esp
...

Тут два важных момента — во-первых порядок помещения аргументов на стек естественно важен. Во-вторых после выполнения системного вызова надо либо вытолкнуть из стека 4 ненужных теперь числа — либо сдвинуть его указатель (регистр ESP) на 4 четырёхбайтовых значения — то есть на 16 байт.

Как можно было бы сделать этот код совместимым с Linux-32? очевидно, волшебный макрос sys_call с четырьмя аргументами мог бы помочь и здесь. Хотя есть и другая волшебная возможность — FreeBSD умеет компилировать код в «совместимом» с Linux режиме.

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

Заключение

Вероятно от раздела про различие и совместимость различных ОС у вас могло остаться лёгкое замешательство. С одной стороны мы понимаем что в принципе программу можно написать в «переносимом» стиле если выработать определенные правила. С другой же — это явно требует определенных усилий и навыка. С переносимостью между 32 и 64 разрядной системами дело явно обстоит похуже чем между Linux и FreeBSD одной разрядности.

Впрочем подобная переносимость (как и вообще программы на ассемблере) нужны в достаточно небольшом количестве случаев — например при написании «бэкенда» компилятора, или каких-либо ассемблерных вставок.

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

© Habrahabr.ru