solutions/01-asm-basics/README.md

Лабораторная работа 1

Введение в низкоуровневое программирование. Встроенный отладчик. Встроенный Ассемблер

Переписываем шаблон

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

Замены требуют следующие функции:

• getch
• delay
• inp
• bioskey

getch

Наиболее простая замена будет для getch(), поскольку единственное ее назначение - ожидать нажатия клавиши. В этом контексте у линукса есть полноценная замена в виде system("pause")

delay

Здесь уже несколько посложнее, потому что DOS'овский delay использует задержку в миллисекундах, а линуксовый sleep - в секундах. Поэтому используем функцию usleep. Она принимает время задержки в микросекундах, поэтому для получения миллисекунда нужно просто умножить на 1000. То есть код:

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> для целей адекватного вывода ошибок. Не обязательно, но предпочтительно

Реализация

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

struct termios saved_attributes;

Далее сразу напишем функцию для восстановления

void reset_input_mode()
{
  tcsetattr (STDIN_FILENO, TCSANOW, &saved_attributes);
}

Здесь STDIN_FILENO - это дескриптор потока стандартного ввода (ввод с консоли по простяге). Вообще это число, но в <unistd.h> он вынесен в макрос для хоть какой-то унификации, TCSANOW - тоже число. В контексте функции tcsetattr оно заставляет изменениям в формате терминала вступить в силу немедленно, вне зависимости от того, есть ли еще в буфере текст на вывод. Другими вариантами могут стать:

• TCSANOW - применить изменения сразу при сигнале и продолжать предыдущий вывод с того же места, где он кончился
• TCSADRAIN - заставит сначала очистить текущий буфер вывода до дна, а только потом сменит режим. То есть сначала все, что было на момент запроса в буфере, будет выведено, а только потом сменится режим терминала
• TCSAFLUSH - то же, что и TCSADRAIN, только еще и сносит весь буффер ввода

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, который говорит, что если буфер не меняется какое-то время, то пользователь закончил

Остальное нам вроде бы знакомо =)

Исправление ассемблерных вставок

Должен сказать, что я не большой поклонник "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