8 Commits

Author SHA1 Message Date
a309019bdb feat: добавлены замеры тиков для последней команды 2024-10-01 22:20:37 +03:00
f2ca981037 fix: убраны дебажные команды 2024-10-01 20:55:08 +03:00
0aed286bcb fix: исправлен недочет при расчете времени 2024-10-01 16:17:15 +03:00
541524bd6f feat: первый прототип для 2 пунтка написан 2024-10-01 15:58:31 +03:00
df80a7190e feat: написаны приготовления для 2 пункта
В приготовления входит макрос для замера времени и предварительно записанные строки для printf
2024-10-01 12:52:23 +03:00
4594912561 feat: решен первый пункт
Этот пункт действительно предполагает просто воспользоваться всеми типами адресации
2024-10-01 12:51:05 +03:00
95df24eaa5 feat: добавлена отдельная логика компиляции для task2
Дело в том, что там я намереваюсь воспользоваться фукнциями стандратной библиотеки Си, поэтому процесс компиляции должен быть особым
2024-10-01 12:49:35 +03:00
53a82c8ea0 feat: скопирован старый Makefile 2024-09-30 15:16:32 +03:00
14 changed files with 283 additions and 304 deletions

67
01-asm-basics/time.asm Normal file
View File

@ -0,0 +1,67 @@
global main
extern printf
%define CLOCK_REALTIME 0
; struct timespec { time_t tv_sec; long tv_nsec; }
struc timespec
.tv_sec: resq 1
.tv_nsec: resq 1
endstruc
section .note.GNU-stack ; чтобы не жаловался линкер
section .bss
start: ; uses timespec model
times 2 resq 1
finish:
times 2 resq 1
section .data
fstring db "Operations took %ul seconds and %ul milliseconds", 10, 0
flen equ $-fstring
section .text
main: ; лично в моей системе time_t представляет из себя long int
mov rax, 228 ; Системный вызов получения времени
mov rdi, CLOCK_REALTIME
mov rsi, start
syscall
; insert your code here
mov rcx, 20000
looper:
mov rax, start
loop looper
mov rax, 228
mov rdi, CLOCK_REALTIME
mov rsi, finish
syscall
; считаем время для секунда и миллисекунд
; секунды
mov rsi, [finish + timespec.tv_sec]
sub rsi, [start + timespec.tv_sec]
; миллисекунды
mov rdx, [finish + timespec.tv_nsec]
sub rdx, [start + timespec.tv_nsec]
mov rdi, fstring
mov rax, 0
sub rsp, 8
call printf
add rsp, 8
exit:
mov rax, 60
mov rdi, 0
syscall

View File

@ -2,171 +2,3 @@
## Система команд процессора, ее связь с кодами команд
## Кодирование команд для x86-64 архитектуры
Преподаватель на ресурсном курсе оставил огромный талмуд Intel (далее именуемый "талмудик" и "талмуд") на тему того, как кодируются команды у их процессоров. И пусть даже наш дорогой препод на лекции дал пояснения по конверсии и прочему, он оставил без ответа вопросы следующего толка: когда какие байты задействованы, где посмотреть опкоды команд и прочие мелочи жизни. Я тот еще программист, поэтому на меня тут не надейтесь, но помогу чем смогу
Перво-наперво структура команды. Приведена она и у препода и в талмудике Intel, повторяться не хочу, но картинку оставлю
![Структура команд](../assets/command_structure.png)
На этой же картинке видно, что может быть от разное количество байт на КОП (который я по привычке именую опкодом), на Displacement, на Immediate и прочем. Да и еще проскакивают надписи `(if required)` и `(optional)`. Вопрос назревает сам собой - а где смотреть-то. И ответ у меня к сожалению не утешительный - в том самом великом и ужасном талмудике (по крайней мере я не нашел другого способа понадежнее). Но тут есть одна так сказать проблемка... Таблички по командам от Intel выглядят мягко скажем как-то так...
![Пример таблицы опкода](../assets/opcode_table_example.png)
Хтонь лично на мой взгляд довольно неприятная, но на самом деле она не так страшна, как вы подумали... Она значительно хуже...
В общем я тут приведу свои пояснения ко всему, что указывают сами Intel, но не в сухую по руководству, а на основе собственного опыта ручного ассемблирования (который, к слову, не очень богат, потому что я еще не успел настолько сойти с ума, чтобы делать работу ассемблера за него)
### Колонка opcode
- `REX.W` - По идее этот префикс может означать много вещей, но на практике пока что я сталкивался с ним только в таком разрезе: если он есть в начале, значит в REX-байте нужно поставить единичку в 3 разряде (4-я цифра справа). Также это означает, что данный байт, вообще говоря, обязателен для функционирования этой команды
- `REX` - Такое встречается, на моей памяти, только рядом с восьмибитными инструкциями и всегда только для того, чтобы к ним тут же приложилось пояснение от intel, что какие-то там проблемы. В общем читайте все это в сносках, потому что сам по себе флаг означает простое наличие REX-байта перед опкодом по всей видимости
- `/digit` - можно порой встретить что-то типа `/0` или `/7`. Когда такое видите, это значит, что в ModR/M байте вместо поля reg нужно записать в двоичной системе то число, которое после слеша. То есть от `000` и до `111`. А все остальное адресуете как раньше
- `/r` - указывает на то, что в ModR/M байте все поля Mod, Reg и R/M используются в стандартном варианте
- `cb`, `cw`, `cd`, `cp`, `co`, `ct` - сам плохо понимаю, что это за покемоны такие. В 64-битных опкодах встречаются редко. Согласно мануалу показывают, сколько битов после опкода следует зарезервировать под смещение для сегмента кода (если вы откроете методичку Милицина, то это тот самый CS или Code Segment). Также согласно талмудику иногда оно может изменить значение сегментному регистру кода. Возможны варианты 1 байт, 2 байта, 4 байта, 6 байт, 8 байт, 10 байт соотвественно.
- `ib`, `iw`, `id`, `io` - Показывают, что после опкода, ModR/M байта (если есть) должен идти непосредственный операнд длиной 1, 2, 4, 8 байт соответственно. Встречается он в таблице обычно там же, где в колонке instruction в соответствующем месте производятся какие-то действия с непосредственными операндами. При чем надо понимать, что нельзя просто опустить байты, которые заполнены нулями, даже если очень хочется и мама разрешила. ставим столько, сколько требует спецификация
- `+rb`, `+rw`, `+rd`, `+ro` - встречается тогда, когда создатели процессора почему-то решили засунуть регистр прям в опкод операнда. Ну, не нам их за это судить. Фактически нам нужно просто глянуть в таблицу которая приведена самими Intel, чтобы определиться только с тем, какое число от 0 до 7 прибавлять. В целом это число является номером регистра, а идут они всегда в следующем порядке: rax, rcx, rdx, rbx, rsp, rbp, rsi, rdi, а также дополнительные регистры r8-r15 работают в том же режиме, то есть начинают нумероваться с нуля. Единственное отличие - бит в REX байте нужно поставить. А вообще табличка должен сказать весьма любопытная, поэтому с ней придется ознакомиться самому. Находится она на 45 странице руководства.
- `+i` - используется в операциях с плавающей точкой. Такие операции любят использовать стек сопроцессора (потому что на самом деле вся арифметика с плавающей точкой аппаратно ускоряется и у нее тоже есть собственная память). Так вот, такой стек обозначается ST(i). Где ST(0) - вершина стека. Не берусь утверждать, но по всей видимости в стеке всего 8 ячеек, потому что по мануалу i может принимать значения от 0 до 7. Соотвественно наша задача просто прибавить это число к байту слева от плюса и на этом все. Больше ничего не требуется
### Колонка instruction
<!---Тут на самом деле говна еще очень много, но я постараюсь описать как можно проще-->
*Обозначений в этой колонке кратно больше, но я буду стараться приводить их кратко. поскольку тут есть регистры на любой вкус и цвет, я буду ставить символ # когда на месте # может быть число от 16 до 64*
- `rel8` - адресация относитльно rip насколько я понимаю. Воспринимается как знаковое число длиной 8 бит, которое прибавится к содержимому rip
- `rel#` - адресация внутри одного сегмента кода (когда в ассемблере начинается `section .text` - это оно). Встречается обычно когда надо обратиться к меткам при прыжках туда и сюда, а оттого встретить можно в `j*` и `call`. Разбиратьсят точнее у меня к сожалению нет возможности
- `r#` - бозначает регистр размером # битов (от 8-битных до 64-битных)
- `m#` - обозначает ячейку памяти размером # бит. периодически можено даже встретить # равное 128, что используется только в SSE и SSE2 инструкциях
- `r/m#` - показывает, что операнд или память (например `[r11 + rcx + 2]`), или регистр (например `rcx`). Если относиться как к памяти, то число `#` указывает не на то, как память адресуется, а сколько битов будет из памяти прочитано, А если как к регистру, то нужно выбирать регистр по размеру, иначе процессор будет жаловаться
- `imm#` - тут `#` может принимать помимо стандартных еще и значение 8. обозначает, что работа ведется с непосредственным операндом (как например в инструкции `mov rax, 12`)
- `moffs#` - сокращение от memory offset - весьма любопытно. Показывает, что программа не использует ModR/M байт. Встречается только в некоторых вариациях `mov`, а адрес задается в качестве смещения относительно базового сегмента (не уверен, что это означает, но думаю относительно сегмента, где сейчас находится rip). Сами интел например на `mov al, moffs8` пишет следующее описание *"Move byte at (seg:offset) to A"*. Также надо понимать, что # задает лишь сколько байтов будет прочитано, а offset задается вполне себе 4 байтами после опкода
- `Sreg` - указывает на использование сегментного регистра. Битовые присвоения для сегментных регистров таковы: e ES = 0, CS = 1, SS = 2, DS = 3, FS = 4, и GS = 5
Остальные инструкции здесь не привожу, поскольку они затрагивают работу с числами с плавающей точкой, векторами и прочими радостями, до которых надеюсь не дойдет
## Как собрать ~~своего покемона~~ свою команду из ассемблера
*оно же: "Да как этой б\*\*\*ской таблицей пользоаться вообще*
![Структура команд](../assets/command_structure.png)
Повторно привожу это изображение. Оно показывает общую структуру команды для процессора. Далее в инструкции я буду обращаться к разным участкам этой команды применяя соответствующие обозначения. Для примера команды можете смотреть на табличку для add в качестве примера того, что можно там увидеть
Самое важное чиселко, которое тут есть - 16-ричное породы "понятно-написанное". Оно - фундамент всего опкода, его мы и берем. А дальше алгоритм следующий:
1. Смотрим, колонку instruction. В ней ищем глазами базу и венец - понятно написанный опкод (это будет скорее всего от двух и до шести 16-ричных цифр). Дальше смотрим, надо ли к нему непосредственно что-то прибавать, и если надо - прибавляем. Ура - мы получили opcode.
2. Как только мы получили опкод, начинаем смотреть налево - если есть приписка REX.W, значит пишем REX байт. Пока что просто ставим заглушку: 0b01001000 или 0x48. Он нам потребуется если мы захотим адресоваться к регистрам с r8 по r15, а до тех пор он будет в заглушечном состоянии. На будущее также отмечу, что выглядит этот байт в общем случае примерно так - 0100 WRXB, где 0100 - обязательная часть, а все к остальным битам я буду адресоваться через точку
3. Далее присматриваемся, надо ли что-то прорезервировать (те самые `cb`) и если непосредственно после опкода ничего не требуется начинаем писать ModR/M байт
4. Написание ModR/M байта пожалуй самый запутанный процесс, но с ним нам должна помочь табличка от Intel. Находятся они в районе 32-34 страниц. Но расскажу так. Поля у ModR/M следующие - 2 битовый mod, потом 3 битный reg, потом 3 битный r/m.
1. mod - указывает на то, как будет адресоваться r/m (третье поле). r/m - сокращение от register/memory. То есть как можно из названия догадаться, только в этом поле процессор может адресовать память компьютера. Это же и есть фундаментальная причина, по которой нельзя заассемблировать команду вроде `mov [addr1], [addr2]`. Возможное содержимое этого поля такого: `00` - Будет адресоваться оперативная память, при чем использоваться будут только регистры (`mov rax, [rdi + rsi*4]`). `01` - будет адресоваться оперативная память и помимо регистра будет еще и смещение, но длиной не больше 1 байта (`add [rbp + rcx - 2], rax`). `10` - то же, что и `01`, но смещение уже занимает 4 байта. `11` - адресоваться будут 2 регистра (`xor rax, rbx`). Если мы поставили что угодно кроме `11` - это надо запомнить, потому что число которое мы записали нужно будет включить в двоичный вид команды использовав взятое нами число байт, а разместить их надо будет либо после ModR/M, либо после SIB байта, если последний будет.
2. reg - указывает регистр, если в колонке opcode не стоит что-то из разряда `/4`. Если стоит, то в reg записывается это число в двоичной форме. Все неиспользованные разряды заполняются нулями. Если длина регистра не вмещается, то самую старшую единицу можно поставить в REX.R
3. R/M - указывает регистр или участок в памяти, который будет адрессоваться. Можем писать сюда номер любого регистра (если не влезет, то расширять его при помощи X бита в REX байте). Однако особенностью тут обладает значение `100`, потому что оно показывает процессору, что нужен SIB байт. При любом другом значении адрес (если mod != 0b11) будет взят из регистра и если есть смещение, оно будет добавлено к значению этого адреса. Единственное, что если mod взят 0b00, то значение 101 тоже магическое - оно затребует 32-битное смещение и использует его в качестве адреса (это точно сработает в 32 битном режиме, но не уверен, что сработает в 64 битах)
5. Если вы взяли такую комбинацию, что вам понадобился SIB байт (а это mod != 11, r/m == 100), то разберемся со структурой байта. Весь этот байт завязан исключительно на адресацию в памяти и состоит из трех побей Scale (SS) в 2 бита, index в 3 бита, base и 3 бита. для разбора полей возьмем следующий пример `[rbx + rcx * 4 + 3]`
1. SS - это scale - это то, на что будет умножаться регистр индекса, при чем это двухбитовое число можно считать степенью двойки. То есть получается 2^(SS) - это коэфициент на который мы умножаем и можем получается умножить на 1, 2, 4 и 8.
2. index - это регистр, который будет умножаться на 2^(SS). Если вы хотите вписать регистры с r8-r15, то невлезающую единицу можно записать в REX.X. В целом же связка SS и index и обеспечивает наличие в адресе в нашем примере `rcx * 4`
3. base - указывает на регистр, значение которого в лоб прибавится к адресу, то есть в нашем примере он отвечает за `rbx`. Если базовый регистр не нужен, на его место ставится `101`
6. После SIB идет displacement байты (1 или 4 в зависимости от поля mod в ModR/M). Заполняем их согласно выделенному количеству
7. После dispacement идет immediate байты - они могут встретиться если в табличке в колонке opcode на этой строке есть что-то похожее на `ib` или другие, которые мы упоминали. заполняем сколько надо
NOTE: По какой-то причине это не указано в руководстве Intel, но по крайней мере если верить сайту, который я использовал для ассемблирования инструкций, то нужно обязательно учитыать префиксы к опкоду прежде чем начинать кодировать (опять же все по опыту):
1. `0x66` - ставится, если программа иссользует хотя бы 1 16-битный регистр
2. `0x67` - ставится если команда **адресуется** при помощи 32-битных регистров
Благо для 8-битных операций другие опкоды и хотя бы на них не надо префиксы запоминать)
## Примеры переводов
Голая теория никого никогда не радовала, поэтому постараюсь в меру своих сил переконвертировать несколько примеров
**`mov rax, rbx`** - исходная инструкция
Для начала в талмудике нам потребуется найти опкод операции. Поэтому ищем табличку для этой операции. В ней нас интересует один из двух покодов: `mov r/m64, r64` и `mov r64, r/m64`. Я возьму второй из этих вариантов, просто чтобы порядок следования регистров совпадал с нашей исходной иструкцией (потом поймете). Для выбранной инструкции приведен следующий opcode: `REX.W + 8B/r`
Для начала посередине ставим опкод (8b в двоичной):
[ 1000 1011 ]
REX байт у нас появляется в любом случае. REX.W - это флаг для REX, который переназначает операнды в размеры 64 бита. Если бы оба наших регистра были бы 32 битные, то этого флага бы не было. Ну а раз REX у нас обязателен, то можно немного определиться, будут ли у нас еще какие-то флаги в этом байте. Еще какие-то флаги могут появиться если вы используете регистры r8-r15, в остальных случаях REX будет выглядеть как [ 0100 1000 ]. У нас эти регистры не используются, поэтому оставим его в таком виде
Промежуточный результат: [ 0100 1000 ] [ 1000 1011 ]
Далее ModR/M. Первые 2 бита от него определяют будут ли использовать адреса и смещения. Подробнее смотрите выше. В нашем случае мы пересылаем из регистра в регистр, поэтому нам нужен mod = 11. Далее идет поле рег. Конкретно в случае `mov r64, r/m64` по контексту можно догадаться что reg у нас слева. Тремя битами кодируется номер регистра. У rax номер 000, а у rbx номер 011. Как я уже и сказал, в нашем случае регистр приемника слева, поэтому ModR/M: [ 11 000 011 ]
Итого: [ 0100 1000 ] [ 1000 1011 ] [ 11 000 011 ]
*примечание: ответ мог бы получиться немного другой, если бы мы взяли первый попавшийся опкод, но можете использовать его в качестве упражнения (ну а что, составители учебника так могут, а я нет?)*
**`mov r8, r11`**
Все действия и рассуждения у нас аналогичны примеру выше. Я хотел лишь пару слов сказать о том, как кодировать регистры r8-r15. Как раз для этих целей нам поможет REX байт. Как я уже писал, REX имеет следующую структуру: 0100 WRXB. Бит R используется для расширения поля reg, а бит B используется для расширения поля r/m. Когда идет обращение к регистру из диапазона r8-r15 в соответствующих дополняющих байтах должна стоять единица. То есть r8 в поле reg будет записываться как REX.R == 1 + 000, а r11 в поле r/m как REX.B == 1 + 011. Так что для данной команды повторится все, кроме REX байта, который в свою очередь примет вид [ 0100 1101 ]
Итого: [ 0100 1101 ] [ 1000 1011 ] [ 11 000 011 ]
**`lea rbx, [rbp + r12 * 4 + 33]`**
Для начала повторяем наш процесс поиска в талмудике опкода. В этот раз у нас разночтений нет, у нас есть только вариант с инструкцией `lea r64, m`. Для нее поле opcode выглядит довольно знакомо: `REX.W 8D /r`. REX байт у нас уже задействован и 100% появится, однако я вижу тут регистр r12, что должно сказать мне, что REX байт не ограничится простым [ 0100 1000 ]. Заполним мы его чуть позже, а пока только опкод. [ 1000 1101 ]
Далее смотрим ModR/M. в нашем случае мы явно будем использовать адрес из оперативной памяти и число 33 для сдвига, поэтому нам нужен режим mod = 01 (можно и 10, но тогда будет куча бесполезных нулей). поле reg не вызывает вопросов - используется регистр rbx, поэтому в REX.R = 0, а reg = 011, а вот с полем r/m все любопытнее. Число, которое идет с плюсом можно пока мысленно вынести за скобки (но не убирать далеко, оно нам еще пригодится), а вот регистры мы уже не можем проморгать. Как мы помним поле r/m хранит только 3 бита, как же адресовать эту адову хренотень? Оказывается в r/m последовательность 100 зарезервирована под добавление еще одного байта - SIB байта. ModRM = [ 01 011 100 ]
SIB байт состоит из 2 битов SS, которые представляют собой степень двойки, 2^(ss) я буду называть коэфициентом. В нашем случае хочу умножить на 4, поэтому ss = 10. Далее идет 3 бита на индекс - это регистр, который будет умножен на коэфициент. В нашем случае мы хотим умножить r12 на 4. Index регистр расширяется из REX.X (потому что inde**X**). Поэтому нам нужно записать двоичной системе 12 - 1100. Старший бит отправится в REX.X, а остальное в поле index, то есть REX.X == 1 index == 100. Далее идет 3 бита под регистр базы. Он расширяется из REX.B, в нашем случае хочется использовать регистр rbp, он имеет номер 0101, поэтому используем REX.B == 0, base == 101. SIB = [ 10 100 101 ]
Уже на этом этапе мы видим, что нужно проставить еще одну единицу в REX.X, в остальных же местах используются обычные регистры, поэтому REX = [ 0100 1010 ].
Помните, мы запоминали число 33? Ну вот настало его время. Дело в том, что число, которое надо прибавить к итоговому адресу. В нашем случае надо закодировать число 33, это будет 0b00100001, это мы засунем в displecement байт
Итого: [ 0100 1010 ] [ 1000 1101 ] [ 01 011 100 ] [ 10 100 101 ] [ 0010 0001 ]
**`inc WORD PTR [2 * rsi + 31]`**
*Интересный факт, в качестве index не может использоваться rsp*
Не буду много повторяться. Внутри опокад стоит `WORD PTR`, что значит, что я самолично попросил ассемблер относиться к содержимому скобок, как к указателю на 1 машинное слово. Возможно также отнестись как к указателю на байт `BYTE`, двойное слово `DWORD` и четверное слово `QWORD`. Instruction `inc r/m16`. Opcode `FF /0`. `/0` означает, что в ModR/M в поле reg нужно записать 3 нуля. Остальное адрессуется как обычно, поэтому самое время обсудить вот какую вещь. Если нам необходимо опустить базу, то в SIB байте мы поставим в поле base 101. Однако для этого в mod нужно поставить 00 и автоматически придется записать 4 байта смещения.
[ 0110 0110 ] [ 1111 1111 ] [ 00 000 100 ] [ 01 110 101 ] [ 0001 1111 ] [ 0000 0000 ] [ 0000 0000 ] [ 0000 0000 ]
Замечу так же, что поскольку не используется ни REX.W ни один из расширенных регистров, REX байт принимал значение 0100 0000, но в таком случае спецификация Intel позволяет этот байт опускать. А вот что опускать нельзя - это префикс переназначения операнда, потому что используется 16 битный регистр.
Число 31 у нас записано справа от SIB байта и у многих наверное появился вопрос, а почему оно выглядит имено так? А точнее - почему 3 последних байта заполнены нулями. Отвечаю - бог его знает и на самом деле, это зависит от процессора, и, возможно, от того, использует ли от little endian или big endian. Little endian - это когда число в памяти записывается как мы привыкли, то есть чем ливее циферка, тем она значительнее. Так что 0x1c1b так в память и запишутся - [ 0001 1100 ] [ 0001 1011 ]. Но вот в случае big endian запись идет по байтам, и если внутри байта все стандартно, то вот сами байты идут уже от младшего к старшему, поэтому то же число запишется уже в обратном порядке как [ 0001 1011 ] [ 0001 1100 ]. Думаю тут такая же фигня
Однако тут есть еще один важный момент Мы видим, что в данном случае есть один интересный момент. Вроде mod == 00, но тут 4 байта dispasement. Дело в том, что если mod == 00 а base == 101, то будет адресация вида index * scale + disp32. Довольно весело. Это я к чему? даже если вы знаете все номера регистры, таблицу смотреть все равно надо
**Послесловие**
Это далеко не исчерпывающий набор примеров, но этого хватит для начала.
## Решение остальных пунктов
*В целом в этом репозитории лежат файлы, в которых я приложил пока еще не протестированное, но решение для первых нескольких пунктов. Однако в силу того, что память у нас 64-битная, а также я не могу залеть напрямую в видеопамять если не буду собирать модуль ядра. Возможно конечно от нечего делать я сделаю модуль ядра, который позволит выворачивать такие приколы, но это будет точно не на время этого курса.*
### 01 - простучать команды ассемблеру
Тут нечего сказать - есть просто колонка с коммандами и просят их использовать. Тут гугл в помощь.
А вот по поводу полей в команде могу сразу сказать - в 64 битном процессоре все это будет выглядеть немного иначе. Поэтому предлагаю 16-битные регистры заменить в команде на 64 битные и закодировать как для 64 разрядной системы. подробная инструкция как это бы надо бы сделать у меня приведена выше, поэтому тут не буду на этом останаваливаться.
### 02 - Пересылка массива при помощи loop и lea
`lea` - это сокращение от "load effective adress". Она использует использует классическую операцию обращения к памяти, но саму память не затрагивает, а просто записывает высчитанный адрес в переменную. `loop` в свою очередь прыгает на определенную метку пока в rcx не окажется 0 и при каждом прыжке уменьшает значение в rcx на 1.
### 03 - Пересылка данных через LODS, MOVS, STOS
LODS и STOS - парные команды. Первая читает из памяти в rax (или его часть), STOS наоборот - пишет в память содержимое rax (или его часть). `movs` перемещает содержимое из [rsi] в [rdi], после чего увеличивает адрес на размер элемента. Это очень хорошо сочетается с префиксом rep, который заставляет повторяет команду пока в rcx не будет 0, а после каждого повторения уменьшает rcx на 1
### 05 - Запись в произвольную память
В линуксе вся память виртуальная, а если попытаться в лоб попробовать написать что-то в рандомный адрес, ядро выдаст segfault. Чтобы этого не произошло необходимо промапать память. Для этого используется системный вызов mmap, про его особенности написано внутри файла. Здесь хотелось бы пояснить вот какой момент: этот системный вызов использует кучу флагов, которые изначально не особенно нам известны. Так вот. Самый быстрый способ найти их - обратиться к include вашего компилятора. Для mmap все лежит в файле <sys/mmap.h>. Эти значения я решил занести в define, чтобы код был чуть читаемее
У mmap есть и другая особенность - он мапает виртуальную память, а не физическую, поэтому то, что в оригинальной методичке мы на самом деле использовали видеобуфер, для нас не имеет реального значения. Я также использовал анонимный приватный маппинг, чтобы не портить жизнь другим процессам и не грузить ничего из файла, поэтому даже попортить жизнь другим процессам у меня не получится
<!--- Пока что я думаю эта инфа лишняя, может потом верну и раскомментирую
### Чутка про префикс REX
Судя по всему, префикс REX стал почти обязателен при переходе на 64 разряда. Что ж, это не удивительно, так как в 64-разрядных системах прибавилось регистров, а их номера нужно где-то и как-то хранить, поэтому это вот такой вот "костылик". На самом деле в талмудике преведены схемы всех подключений, которые я пока не привожу, потому что это не самое главное, но может потом добавлю
Вот что они пишут про префик REX во второй главе своего талмуда: "Префикс REX указывается не всегда в 64-разрядном режиме. Он необходим только тогда, когда инструкция адресуется к одному из рассширенных регистров или использует 64-разрядные операнды". То есть условно говоря если работам с 64 разрядами, то RAX нужен, а если нет - его может и не быть, если явно не сказано иное. Сами же REX - это 16 опкодов, которые берут пространство от 0x40 до 0x4F. В режиме режиме обратной совместимости и IA-32 отражают опкоды реальных инструкций, но нас естественно интересует режим 64 разрядов, а в нем они как отдельная инструкция не трактуются и идут только в связке. Также почему-то интел сокрушаются, что из-за этого однобайтовый опкод для инкреммента и декремента перестал существовать в 64 разрядных системах
-->

View File

@ -1,18 +0,0 @@
#!/usr/bin/python3
import argparse
def hex2bin(hexNum: str) -> None:
return bin(int(hexNum, 16))
parser = argparse.ArgumentParser(description="Convert hex number to bin right in terminal")
parser.add_argument('-s', '--stdin', action='store_true', help="if passed takes input from stdin")
parser.add_argument('number', nargs='?')
args = parser.parse_args()
if args.stdin:
print(hex2bin(input()))
elif args.number:
print(hex2bin(args.number))
else:
print("something went wrong")

View File

@ -1,29 +0,0 @@
global _start
section .data
source: db 1, 2, 3, 4, 5, 6, 7, 8
s_size equ $-source
section .bss
dest: resb 8
section .text
_start:
lea rsi, [source]
lea rdi, [dest]
mov rcx, s_size
.loop:
mov al, [rsi + rcx]
mov [rdi + rcx], al
loop .loop
mov rax, 60
mov rdi, 0
syscall

View File

@ -1,25 +0,0 @@
global _start
section .data
source: db 1, 2, 3, 4, 5, 6, 7, 8
s_size equ $-source
section .bss
dest: resb 8
section .text
_start:
mov rsi, source
mov rdi, dest
mov rcx, s_size
.loop:
rep movsb
loop .loop
mov rax, 60
mov rdi, 0
syscall

View File

@ -1,64 +0,0 @@
global _start
section .text
%define SRC 0xB8000
%define DST 0xB9000
%define ARR_SIZE 10
%define PROT_READ 0x1
%define PROT_WRITE 0x2
%define MAP_PRIVATE 0x02
%define MAP_ANONYMOUS 0x20
_start:
; Из-за особенностей ядра линукса нужно сначала промапать произвольную память
mov rax, 0x9 ; mmap
mov rdi, SRC ; где
mov rsi, ARR_SIZE ; сколько
mov rdx, PROT_READ ; флаги чтения
or rdx, PROT_WRITE ; флаги записи
mov r10, MAP_PRIVATE ; приватная память
or r10, MAP_ANONYMOUS ; не связана с файлом
mov r9, 0 ; офсет должен быть 0
syscall
mov rsi, rax ; ставлю так, так как ядро линукса выделяет ближайшую область памяти, а не точно заказанную - проклятое выравнивание
; заполню чем-нибудь массив
mov rcx, ARR_SIZE
mov rbx, 0
.fill_src_loop:
mov [rsi + rbx], bl
inc rbx
loop .fill_src_loop
push rsi
mov rax, 0x9 ; mmap
mov rdi, DST ; где
mov rsi, ARR_SIZE ; сколько
mov rdx, PROT_WRITE ; флаги чтения
; or rdx, PROT_WRITE ; флаги записи
mov r10, MAP_PRIVATE ; приватная память
or r10, MAP_ANONYMOUS ; не связана с файлом
mov r9, 0 ; офсет должен быть 0
syscall
mov rdi, rax
; заполню чем-нибудь массив
mov rcx, ARR_SIZE ; сколько байт копируем
pop rsi
rep movsb
mov rax, 60
mov rdi, 0
syscall

13
03-asm-bios/Makefile Normal file
View File

@ -0,0 +1,13 @@
ASM = nasm
ASM_FLAGS = -felf64 -g
LINK = ld
%: %.o
$(LINK) -o $@ $^
%.o: %.asm
$(ASM) $(ASM_FLAGS) $^ -o $@
clean:
rm -f *.o
rm -f $(subst .asm, $(empty), $(wildcard *.asm))

18
04-addr-methods/Makefile Normal file
View File

@ -0,0 +1,18 @@
ASM = nasm
CXX = gcc
CXX_FLAGS = -Os -static
ASM_FLAGS = -felf64 -g
LINK = ld
task2: task2.o
$(CXX) $(CXX_FLAGS) $^ -o $@
%: %.o
$(LINK) -o $@ $^
%.o: %.asm
$(ASM) $(ASM_FLAGS) $^ -o $@
clean:
rm -f *.o
rm -f $(subst .asm, $(empty), $(wildcard *.asm))

33
04-addr-methods/task1.asm Normal file
View File

@ -0,0 +1,33 @@
global _start
section .data
%macro FILL_ASC 1
%assign NUM 0
%rep %1
db NUM
%assign NUM NUM + 1
%endrep
%endmacro
example: FILL_ASC 256
section .text
_start:
; В качестве базы возьму inc
; регистровая
inc ecx
mov rax, example
; косвенно-регистровая
inc byte [rax]
; "Индексно-базовая", хотя у меня почти все может быть базой
inc byte [rax + rbx]
; "Индексно-базовая" со смещением
inc byte [rax + rbx + 122]
; Ну в целом... все
mov rax, 60
mov rdi, 0
syscall

139
04-addr-methods/task2.asm Normal file
View File

@ -0,0 +1,139 @@
global main
extern printf
struc timespec ; структура, в которой линукс хранит время. Тут нужна для удобства в будущем
.tv_sec: resq 1
.tv_nsec: resq 1
endstruc
%include "timer.inc"
section .note.GNU-stack
section .data
example: times 128 db 127
section .bss
; uses timespec model
start: resq 2
finish: resq 2
deltatime: resq 2
section .text
%macro PUSH_M 1-*
%rep %0
push %1
%rotate 1
%endrep
%endmacro
%macro RPOP_M 1-*
%rotate -1
%rep %0
pop %1
%rotate -1
%endrep
%endmacro
%define CLOCK_REALTIME 0
%macro TIME_1_000_000 0-1+ ; принимает команду, которую будет пытаться обмерить по времени
PUSH_M rax, rdi, rsi, rcx
mov rax, 228 ; Время начала
mov rdi, CLOCK_REALTIME
mov rsi, start
syscall
RPOP_M rax, rdi, rsi, rcx
mov rcx, 10000000000; выполняем миллион раз
%%loop:
%1
loop %%loop
PUSH_M rax, rdi, rsi, rcx
mov rax, 228 ; Время конца
mov rdi, CLOCK_REALTIME
mov rsi, finish
syscall
RPOP_M rax, rdi, rsi, rcx
; считаем секунды
push rax ; можно было бы оптимизировать, но мне лень макросы переписывать
mov rax, [finish + timespec.tv_sec]
sub rax, [start + timespec.tv_sec]
mov [deltatime + timespec.tv_sec], rax
; считаем наносекунды
mov rax, [finish + timespec.tv_nsec]
sub rax, [start + timespec.tv_nsec]
jns %%save_result
dec qword [deltatime + timespec.tv_sec] ; занимаем миллиард наносекунд
add rax, 1000000000 ; прибавляем занятый разряд
%%save_result:
mov [deltatime + timespec.tv_nsec], rax
pop rax
%endmacro
%macro PRINT_DELTATIME 1
;sub rsp, 8
mov rdi, str_template
mov rsi, %1
mov rdx, [deltatime + timespec.tv_sec]
mov rcx, [deltatime + timespec.tv_nsec]
call printf
;add rsp, 8
%endmacro
main:
push rbp
mov rbp, rsp
sub rsp, 16
xor rax, rax ; поскольку приходим сюда из компилятора, лучше обнулить
TIME_1_000_000
PRINT_DELTATIME nop_command
TIME_1_000_000 inc rax
PRINT_DELTATIME reg_command
mov rax, example
TIME_1_000_000 inc byte [rax]
PRINT_DELTATIME rel_reg
mov rax, example
xor rbx, rbx
TIME_1_000_000 inc byte [rax + rbx]
PRINT_DELTATIME ind_base
mov rax, example
xor rbx, rbx
TIME_1_000_000 inc byte [rax + rbx + 122]
PRINT_DELTATIME ind_base_disp
; Под конец давайте посчитаем тактовую частоту на примере той же самой команды
rdtsc
mov [rbp - 4], edx
mov [rbp - 8], eax
mov rcx, 10000000000
mov rax, example
xor rbx, rbx
.loop:
inc byte [rax + rbx + 122]
loop .loop
rdtsc
sub eax, [rbp - 8]
sbb edx, [rbp - 4]
mov [rbp - 8], eax
mov [rbp - 4], edx
mov [rbp - 16], rsp
and rsp, -16
mov rdi, tick_count
mov rsi, [rbp - 8]
call printf
mov rsp, rbp
pop rbp
xor rax, rax ; сообщаем gcc, что все закончилось успешно
ret

13
04-addr-methods/timer.inc Normal file
View File

@ -0,0 +1,13 @@
section .data
str_template: db "Command %s took %lld seconds and %lld nanoseconds to execute 1 000 000 000 times", 10, 0
template_len equ $-str_template
nop_command: db '`empty loop`', 0
reg_command: db '`inc ebx`', 0
rel_reg: db '`inc byte [rax]`', 0
ind_base: db '`inc byte [rax + rbx]`', 0
ind_base_disp: db '`inc byte [rax + rbx + 122]`', 0
tick_count: db 'Last command also took %lli ticks to complete', 10, 0

Binary file not shown.

Before

Width:  |  Height:  |  Size: 9.5 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 16 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 142 KiB