147 lines
18 KiB
Markdown
147 lines
18 KiB
Markdown
# Лабораторная работа 1
|
||
|
||
## Введение в низкоуровневое программирование. Встроенный отладчик. Встроенный Ассемблер
|
||
|
||
## Переписываем шаблон
|
||
|
||
Поскольку весь шаблонный текст написан под 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, которые зависят от системы или архитектуры. **Не мудрено, что и системные вызовы тоже хранятся где-то в заголовках**. Однако я тут ничего не подскажу, так как так и не понял, где эти номера нормально записаны. Если вы знаете - пишите.
|