fix: подправил графу про rel

Это вряд ли исчерпывающее руководство как собирать инструкции, но оно подходит для сборки самых разных инструкций только чтением методички от intel

01-asm-basics/README.md

@@ -2,145 +2,3 @@
 
 ## Введение в низкоуровневое программирование. Встроенный отладчик. Встроенный Ассемблер
 
-## Переписываем шаблон
-
-Поскольку весь шаблонный текст написан под MS-DOS, мы очевидным образом не можем его использовать для решения задачи под linux. 
-
-Замены требуют следующие функции:
-
-- getch
-- delay
-- inp
-- bioskey
-
-### getch
-
-Наиболее простая замена будет для `getch()`, поскольку единственное ее назначение - ожидать нажатия клавиши. В этом контексте у линукса есть полноценная замена в виде `system("pause")`
-
-### delay
-
-Здесь уже несколько посложнее, потому что DOS'овский `delay` использует задержку в миллисекундах, а линуксовый `sleep` - в секундах. Поэтому используем функцию `usleep`. Она принимает время задержки в микросекундах, поэтому для получения миллисекунда нужно просто умножить на 1000. То есть код:
-
-```C
-void delay(unsigned ms)
-{
-    usleep(ms * 1000);
-}
-```
-
-### bioskey
-
-Из всех пока что самая сложная замена. Если вызвать `bioskey(1)`, то она вытаст 1 если какая либо клавиша была нажата и 0 если не была. при этом проверка происходит в моменте и не блокирует выполнение программы.
-
-Для иммитации этого на линуксе нам потребуется неканонический режим ввода в терминал, а также сделать так, чтобы все печатаемое не выводилось в курсор. Этого можно добиться 2 способами: 
-
-1. Покурить гигагалактический томик по ассемблеру и узнать про системный вызов ioctl, после чего руками разметить область оперативной памяти, провести все системные вызовы, потом при помощи poll проверять наличие символов в буфере, обрабатывать ошибки и интегрировать функции через прототипы в наш код на C
-2. Сдаться и выбрать путь языка C
-
-Я уже сказал, что я из слабых, поэтому писать кусок на ассемблере как-то не горю желанием (хотя может когда-нибудь в будущем по просьбам напишу)
-
-#### Зависимости
-
-Язык программирования C имеет определенный уровень абстракции от конкретных системных вызовов и предоставляет нам несколько вещей:
-
-- `<termios.h>` - структура данных, хранящая информацию о текущем состоянии терминала, а также удобные методы `tcgetattr` и `tcsetattr`
-- `<unistd.h>` - Библиотека, используемая для унификации дескрипторов, битов и прочих унификаций
-- `<stdlib.h>` - много чего, но нам для безопасности потребуется `atexit`, чтобы если что-то пошло не так, у нас не наебнулся терминал
-
-Опционально берется `<stdio.h>` для целей адекватного вывода ошибок. Не обязательно, но предпочтительно
-
-#### Реализация
-
-Для начала нам необходимо сохранить свой текущий терминал, чтобы без проблем его восстановить в будущем, для этого заводим в памяти переменную (придется сделать ее глобальной, потому что на инкапсуляцию и защиту нет времени, нервов и желания)
-
-```C
-struct termios saved_attributes;
-```
-
-Далее сразу напишем функцию для восстановления
-
-```C
-void reset_input_mode()
-{
-  tcsetattr (STDIN_FILENO, TCSANOW, &saved_attributes);
-}
-```
-
-Здесь `STDIN_FILENO` - это дескриптор потока стандартного ввода (ввод с консоли по простяге). Вообще это число, но в `<unistd.h>` он вынесен в макрос для хоть какой-то унификации, `TCSANOW` - тоже число. В контексте функции `tcsetattr` оно заставляет изменениям в формате терминала вступить в силу немедленно, вне зависимости от того, есть ли еще в буфере текст на вывод. Другими вариантами могут стать:
-
-- `TCSANOW` - применить изменения сразу при сигнале и продолжать предыдущий вывод с того же места, где он кончился
-- `TCSADRAIN` - заставит сначала очистить текущий буфер вывода до дна, а только потом сменит режим. То есть сначала все, что было на момент запроса в буфере, будет выведено, а только потом сменится режим терминала
-- `TCSAFLUSH` - то же, что и `TCSADRAIN`, только еще и сносит весь буффер ввода
-
-```C
-void set_input_mode()
-{
-  struct termios tattr;
-  char *name;
-
-  // Убеждаемся, что STDIN - это терминал
-  if (!isatty (STDIN_FILENO))
-    {
-      fprintf (stderr, "Not a terminal.\n");
-      exit (EXIT_FAILURE);
-    }
-
-  // Сохраняем параметры текущего терминала 
-  //для последующего восстановления
-  tcgetattr (STDIN_FILENO, &saved_attributes);
-  atexit (reset_input_mode);
-
-  // Устанавливаем все режимы, которые
-  // нас в общем-то интересуют
-  tcgetattr (STDIN_FILENO, &tattr);
-  tattr.c_lflag &= ~(ICANON|ECHO); /* Clear ICANON and ECHO. */
-  tattr.c_cc[VMIN] = 0;
-  tattr.c_cc[VTIME] = 0;
-  tcsetattr (STDIN_FILENO, TCSAFLUSH, &tattr);
-}
-```
-
-**Разберем некоторые строки подробнее**
-
-`isatty(STDIN_FILENO)` - в целом `isatty` просто проверяет, является ли дескриптор файла консолью в общем смысле этого слова. Вообще в линуксе `tty` означает teletype - консоли, которые могут использоваться для выполнения команд, восстановления системы и прочего. В некоторых дистрибутивах между ними можно даже переключаться, но так как я на wsl, мне эта роскошь не доступна
-
-`fprintf` - функция, позволяющая делать "форматированный вывод" в поток дескриптора. То есть это как `prinf`, только еще и дескрипторы принимает
-
-`EXIT_FAILURE` и `EXIT_SUCCESS` - обозначают 1 и 0 соответственно. Используются чтобы избежать неявной договоренности между пользователями линукс, что при возвращении нуля из функции - это успех, а другого - ошибка
-
-Очевидным образом если `tcsetattr` устанавливал параметры терминала, то `tcgetattr` должен их получать. В качестве второго параметра принимает указатель на структуру данных, где должен их сохранить. В нашем случае ей выступает упоминавшаяся выше глобальная переменная
-
-После получения параметров мы начинаем c ними играться в флагах. В данном случае я вырубаю `ICANON` тем самым говоря, что вводить `enter` при вводе команд не обязательно, а также рублю флаг `ECHO`, из-за чего набираемые с клавиатуры символы не отображаются
-
-`VMIN` говорит о том, что одного символа в буфере достаточно, чтобы считать, что пользователь ввел все, что хотел. Есть еще параметр `VTIME`, который говорит, что если буфер не меняется какое-то время, то пользователь закончил
-
-Остальное нам вроде бы знакомо =)
-
-<!---Тут следует следить за обновлениями кода в substitutions.py, а то неактуальный код - большая беда-->
-
-## Исправление ассемблерных вставок
-
-Должен сказать, что я не большой поклонник "inline assembly". На мой субъективный взгляд намного лучше, читаемее и стабильнее добавлять ассемблер на этапе линковки. Это дает несколько приятных бонусов:
-
-1. Код можно поддерживать на любимом ассемблере
-2. Код ассемблера можно компилить отдельно
-3. Код программы на C становится ощутимо чище (*лично на мой взгляд ассемблерные вставки плохо смотрятся в коде*), а также все макросы ассемблера не касаются кода на C
-4. Меньше потенциальных ошибок из-за того, что вы что-то не так поняли и откомпилировалось все неправильно
-
-Помимо прочего очень важный момент: я использую gcc для компиляции, а в отличие от clang, он довольно ленивый и наши строки для ассемблера в нетронутом виде отправятся прямо в текст программы, которая затем будет скормлена ассемблеру. Отсюда следует несколько нюансов:
-
-- Стандартный ассемблер, используемый `gcc` - `as` и по умолчанию он использует синтаксис AT&T. Однако я не очень люблю этот синтаксис, предпочитаю работать с синтаксисом intel. Выхода тут 2:
-    - Дать компилятору флаг -masm=intel, после чего уже собственный ассемблер переключится на intel синтаксис
-    - В начале каждой ассемблерной вставки ставить ".intel_syntax noprefix", а после вставки но перед параметрами ставить ".att_syntax prefix". Это может периодически плохо работать
-- При написании ассемблера необходимо соблюдать все переносы строк и при этом указывать это явно (поэтому в конце строк у меня и появляются `\n\t` - это поддержание табуляции и переноса строки
-- Компилятору надо понимать, что будет происходить с переменными и регистрами во время ассемблерной вставки, поэтому и это тоже придется указать отдельно
-
-Собственно видно, что есть ньансы, которые и заставляют меня сделать выбор в пользу обычного ассемблера и линковки, но раз лаба хочет, чтобы использовался именно inline, то будем использовать inline
-
-UPD 12.09.24 22:00: в самый последний момент преподаватель решил в своей методички пингануть адрес в памяти, который в ms-dos отведен для хранени данных BIOS, а конкретнее ту часть, которая отведена под системные часы насколько я понимаю. В случае DOS это вполне себе реальная память, которая вполне себе реально существует более того, в досе процессор находится в режиме реальных адресов. Linux в свою очередь относится к приколам с обращением к произвольному участку памяти как к уязвимостям, поэтому не дает просто почитать или пописать в непромапаную память. Но это пол беды на самом-то деле, ведь вся память у любой программы виртуальная и уже на уровне операционной системы и процессора перегонятся в виртуальную, поэтому даже если я воспользуюсь `mmap` и промапаю соответствующий адрес в памяти, в нем будет просто лежать мусор и не более. Поэтому последнюю часть работы, где достается время из памяти BIOS я пропускаю за невозможностью ее выполнить на машине на базе Linux
-
-## Замеры времени ассемблерной команды
-
-Мне лабораторную работу зачли и без этой части, но если кто-то будет сдавать ему лабу так же как и я, такое возможно не проканает, поэтому для решения задачи замера приложен файлик time.asm (по крайней мере должен быть, если я не забыл). В нем в комментариях я постарался пояснить все этапы замера времени. Но для базового понимания придется сделать некоторые пояснения относительно организационных решений. В методичке преподаватели предпочли обратиться к чтению из промапаной области памяти BIOS, так называемой BIOS data area. Неплохой вариант, если есть прямой доступ к памяти устройства, поскольку BIOS хранит в памяти довольно много полезных данных. Однако из пользовательских программ простучать эту память не получается, потому что linux будет выдавать ошибку даже если такие программы запускать под рутом.
-
-Однако как же тогда получать время и делать другие манипуляции? Довольно просто на самом деле - системными вызовами. Системный вызов - это программное прерывание, которое просит операционную систему в режиме ядра выполнить какую-то работу: получить время, установить время, поменять разрешения на порты, сменить режимы терминала и очень многое другое вплоть до создания X-server'а. Найти системные вызовы можно прогуглив `linux syscalls table`. От себя порекомендую этот [сайт](https://syscalls.mebeim.net/?table=x86/64/x64/latest). Они вытаскивают системные вызовы из каждой версии ядра. Также возможный, пусть и требующий значительно больше знаний вариант - посмотреть стандартную библиотеку вашего компилятора C. Дело в том, что сам язык C довольно мал и весь его огромный функционал завязан на не таком уж и большом количестве зарезервированных слов и конструкций. В целом сопоставление между C и ассемблером, если компилировать без оптимизаций компилятора (`-O0`), выходит довольно однозначное. И эта же особенность заставляет постоянно переписывать те библиотеки в C, которые зависят от системы или архитектуры. **Не мудрено, что и системные вызовы тоже хранятся где-то в заголовках**. Однако я тут ничего не подскажу, так как так и не понял, где эти номера нормально записаны. Если вы знаете - пишите.

01-asm-basics/main.c

@@ -1,135 +0,0 @@
-#include <stdio.h>
-#include <sys/io.h>
-#include <stdlib.h>
-#include <unistd.h>
-
-#include "substitutions.h"
-
-#define PortCan0 0x40
-
-void beep(unsigned iTone, unsigned iDlit);
-
-void delay(unsigned int ms)
-{
-  usleep(ms * 1000);
-}
-
-int main(void) {
-
-  long int lCnt = 0;
-  int iA = 0x1234;
-
-  char *pT = (char *)0x46C;
-  printf("\nПечатаем 10 раз значение байта с известным адресом\n");
-  for (int i = 0; i < 10; i++)
-  {
-    printf(" \n  %d ", *pT);
-  }
-  printf("\n Для продолжения нажмите любую клавишу \n");
-  system("pause"); // Ждем нажатия клавиши
-
-  printf("\n Читаем содержимое порта с адресом 40 с помощью функции Си \n");
-  printf("\n Для выхода из цикла - нажмите любую клавишу \n");
-
-  // Линуксу не сильно нравится, что ты насилуешь порты ввода и вывода процессора, поэтому нужно выдать ему на это дело разрешение
-
-  ioperm(PortCan0, 1, 3); // Что означает тройка напишу позже
-  set_input_mode();
-  while (isKeyPressed() == 0) {
-    printf("\n Порт40 = %d", inb(PortCan0));
-    delay(500);
-  }
-  reset_input_mode();
-
-  system("pause");
-  printf("\n Читаем содержимое порта с адресом 40 ассемблером \n");
-
-  set_input_mode();
-  while (isKeyPressed() == 0) {
-//    asm { 
-//     push ax    
-//     in al,0x40
-//    }
-
-    unsigned char Tmm = 0;
-    asm (
-    "push rax\n\t"
-    "in al, 0x40"
-    "mov %0, al"
-    "pop rax"
-    :"=r"(Tmm)
-    :
-    :"rax"
-    );
-    delay(500);
-    printf("\n Порт40 = %d", Tmm);
-  }
-  reset_input_mode();
-  system("pause");
-  printf("\n Для продолжения - нажмите любую клавишу \n");
-  system("pause");
-
-  long *pTime = (long *)0x46C;
-  set_input_mode();
-  while (isKeyPressed() == 0) {
-    printf("\n %ld", *pTime);
-    delay(1000);
-  }
-  reset_input_mode();
-  system("pause");
-
-  // Данная секция закомментирована, поскльку линукс не дает обратиться к
-  // не промапанной и не аллоцированной памяти. Но даже если ее аллоцировать 
-  // mmem'ом, все равно эта память будет виртуальная, поэтому смысла делать
-  // это не имеет. Вариант просмотра содержимого условной ячейки памяти на nasm
-  // приведен в файле time.asm. Объяснить тот код, который я вижу
-  // на базовом уровне я в состоянии
-
-//  int Time;
-//  set_input_mode();
-//  while (isKeyPressed() == 0) {
-//     Здесь происходит операция получения времени суток при 
-//     помощи обращения к специально размеченой области памяти
-//     Однако можно ли такой фокус сделать в linux это еще надо узнать
-//    asm push ds
-//    asm push si
-//    asm mov ax, 40h
-//    asm mov ds, ax
-//    asm mov si, 0x6C
-//    asm mov ax, [ds : si]
-//    asm mov Time, ax
-//    asm pop si
-//    asm pop ds
-//    asm(
-//    "mov "
-//    );
-//
-//    printf("\n %d", Time);
-//    delay(300);
-//  }
-//  reset_input_mode();
-//
-//  beep(400, 200);
-//  for (lCnt = 0; lCnt < 1000000; lCnt++) {
-//  a1:
-//    asm { 
-//      mov ax,iA
-//      mov ax,iA
-//      mov ax,iA
-//      mov ax,iA
-//      mov ax,iA
-//      mov ax,iA
-//      mov ax,iA
-//      mov ax,iA
-//      mov ax,iA
-//    a2:
-//      mov ax,iA
-//      }
-//  }
-//  beep(400, 200);
-
-  // здесь секция для выполнения замеров времени. Поскольку доступ к звуку
-  // Я иметь не могу, если не буду использовать pulseaudio, замерим старыми дедовскими методами
-  // При помощи clock_gettime
-}
-

01-asm-basics/substitutions.c

@@ -1,63 +0,0 @@
-#include "substitutions.h"
-#include <unistd.h>
-#include <stdio.h>
-#include <stdlib.h>
-#include <termios.h>
-#include <time.h>
-
-/* Use this variable to remember original terminal attributes. */
-
-struct termios saved_attributes;
-
-void reset_input_mode()
-{
-  tcsetattr (STDIN_FILENO, TCSANOW, &saved_attributes);
-}
-
-void set_input_mode()
-{
-  struct termios tattr;
-  char *name;
-
-  /* Make sure stdin is a terminal. */
-  if (!isatty (STDIN_FILENO))
-    {
-      fprintf (stderr, "Not a terminal.\n");
-      exit (EXIT_FAILURE);
-    }
-
-  /* Save the terminal attributes so we can restore them later. */
-  tcgetattr (STDIN_FILENO, &saved_attributes);
-  atexit (reset_input_mode);
-
-  /* Set the funny terminal modes. */
-  tcgetattr (STDIN_FILENO, &tattr);
-  tattr.c_lflag &= ~(ICANON|ECHO); /* Clear ICANON and ECHO. */
-  tattr.c_cc[VMIN] = 0;
-  tattr.c_cc[VTIME] = 0;
-  tcsetattr (STDIN_FILENO, TCSAFLUSH, &tattr);
-}
-
-void delay(unsigned int ms)
-{
-  usleep(ms * 1000);
-}
-
-char isKeyPressed()
-{
-  char key_handler = 0;
-  read(STDIN_FILENO, &key_handler, 1);
-  if (key_handler > 0)
-  {
-    return 1;
-  }
-  return 0;
-}
-
-int main()
-{
-  set_input_mode();
-  while (isKeyPressed() == 0) {printf("hell\n");}
-  printf("ok\n");
-  reset_input_mode();
-}

01-asm-basics/substitutions.h

@@ -1,9 +0,0 @@
-#ifndef SUBSTITUTIONS_H
-#define SUBSTITUTIONS_H
-
-void reset_input_mode();
-void set_input_mode();
-void delay(unsigned int ms);
-char isKeyPressed();
-
-#endif

01-asm-basics/time.asm

@@ -1,97 +0,0 @@
-; Эта директива делает функцию видимой.
-; По умолчанию в ассемблере используется _start,
-; но поскольку для вывода на экран я пользуюсь
-; С'шной функцией prinf, для корректного подключения библиотек на этапе линковки
-global main
-
-; Объявляю, что буду ссылаться на метку printf, которой нет внутри кода программы
-; extern вообще обзначает, что метка объявлена где-то еще
-extern printf
-
-; тут объявлен макрос CLOCK_REALTIME, который на этапе ассемблирования заменится на число 0
-; Использован он тут, так как является clock_id, о котором будет сказано позже. И я не уверен
-; что на всех системах это число будет одинаково. Свое я посмотрел в файлах компилятора.
-%define CLOCK_REALTIME 0
-
-; так в ассемблере задаются структуры. Существуют они лишь на уровне препроцессора
-; да и применение их весьма специфично. Но подробнее лучше погуглите
-; struct timespec { time_t tv_sec; long tv_nsec; } - это шаблон из C
-struc timespec
-  .tv_sec: resq 1
-  .tv_nsec: resq 1
-endstruc
-
-section .note.GNU-stack ; чтобы не жаловался линкер
-
-; Секция с данными, ее особенность в том, что нужно указать лишь сколько нужно зарезервировать
-section .bss
-; вообще можно было бы использовать istruc и создать эти 2 структуры в .data, но я решил,
-; что не хочу тратить время на инициализацию того, что и так будет перезаписано
-; обе эти инструкции просто нужны чтобы застолбить по 16 памяти на каждый замер времени
-; потому что time_t и long имеют размер 8 байт, а поля 2
-start:
-  resq 2
-
-finish:
-  resq 2
-
-; Секция с данными, которые заранее заполняются чем-то
-section .data
-
-  fstring db "Operations took %ul seconds and %ul nanoseconds", 10, 0 ; строки стиля C должны оканчиваться нулем
-  flen equ $-fstring ; длина строки. $ - это текущий адрес. Подробнее не буду рассказывать - мне лень
-
-section .text
-
-main: ; лично в моей системе time_t представляет из себя long int
-  mov rax, 228 ; Системный вызов получения времени
-  mov rdi, CLOCK_REALTIME
-  mov rsi, start
-  syscall
-
-  ; здесь место для кода под замер времени
-  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]
-
-  ; вызываем функцию printf. Согласно соглашению о вызовах fastcall
-  ; при вызове функций для передачи аргументов используются регистры по порядку следования аргументов
-  ; rdi, rsi, rdx, rcx, r8, r9, а остальные пушатся в ассемблер.
-  ; Свои заморочки там с числами с плавающей точкой, но об этом не сейчас
-  mov rdi, fstring
-  mov rax, 0
-  ; Вот тут все во имя выравнивания стека. Об этом я сейчас рассказывать не буду, только если попросят в readme чиркану
-  sub rsp, 8
-  ; собственно вызов функции. На самом деле это обычный jmp, который предварительно пушит в стек адрес возврата.
-  ; в будущем будьте аккуратнее с этими приколами, потому что при встрече ключевого слова ret ассемблер всегда.
-  ; подчеркиваю ВСЕГДА прочитает 8 байт со стека и передаст туда управление. И как бы что там будет - одному богу ведомо
-  ; Так что в ваших же интересах следить за тем, чтобы в стеке лежали правильные байты
-  call printf
-  ; поскольку выравнивание больше не нужно, возвращаем стек в исходное состояние
-  add rsp, 8
-
-exit:
-  ; Тут происходит системный вызов выхода из приложения. Если его не увидит 
-  ; linux, то он решит, что программа завершилась аварийно
-  mov rax, 60
-  mov rdi, 0 ; код ошибки. если вернется 0 - считается, что ошибок не произошло
-  syscall
-

02-cpu-commnads/README.md

@@ -2,3 +2,87 @@
 
 ## Система команд процессора, ее связь с кодами команд
 
+## Кодирование команд для 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. `0x67` - ставится если команда **адресуется** при помощи 32-битных регистров
+2. `0x66` - ставится, если программа иссользует хотя бы 1 16-битный регистр
+
+Благо для 8-битных операций другие опкоды и хотя бы на них не надо префиксы запоминать)
+
+<!--- Пока что я думаю эта инфа лишняя, может потом верну и раскомментирую
+### Чутка про префикс REX
+
+Судя по всему, префикс REX стал почти обязателен при переходе на 64 разряда. Что ж, это не удивительно, так как в 64-разрядных системах прибавилось регистров, а их номера нужно где-то и как-то хранить, поэтому это вот такой вот "костылик". На самом деле в талмудике преведены схемы всех подключений, которые я пока не привожу, потому что это не самое главное, но может потом добавлю
+
+Вот что они пишут про префик REX во второй главе своего талмуда: "Префикс REX указывается не всегда в 64-разрядном режиме. Он необходим только тогда, когда инструкция адресуется к одному из рассширенных регистров или использует 64-разрядные операнды". То есть условно говоря если работам с 64 разрядами, то RAX нужен, а если нет - его может и не быть, если явно не сказано иное. Сами же REX - это 16 опкодов, которые берут пространство от 0x40 до 0x4F. В режиме режиме обратной совместимости и IA-32 отражают опкоды реальных инструкций, но нас естественно интересует режим 64 разрядов, а в нем они как отдельная инструкция не трактуются и идут только в связке. Также почему-то интел сокрушаются, что из-за этого однобайтовый опкод для инкреммента и декремента перестал существовать в 64 разрядных системах
+-->

02-cpu-commnads/hex2bin.py

@@ -0,0 +1,18 @@
+#!/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 terminal arguments")
+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")
+