diff --git a/README.md b/README.md index 7f296be..4672e51 100644 --- a/README.md +++ b/README.md @@ -2,7 +2,56 @@ ## Лабораторный практикум -### Содержание +### Что в здесь находится + +В данном репозитории находятся "отчеты" к лабам - авторское описание порядка действий для решения лабы. Все, что не является исходником программы будет лежать в формате .md файла. + +### Используемое ПО + +### Стандартный набор + +Если вы находитесь под крылышком у Милицына, то вам нужен следующий набор: + +- Windows XP: операционная система. Вам он ее даст в виде установочного образа и на ней вы найдете все остальные программы +- Borland C for DOS - лежит в каталоге BIN папки BORLAND под названием BC +- Turbo Debugger - Можно вызвать из под Borland C for DOS при помощи нажатия на зачем-то оставшуюся там букву Ё. + +### Авторский набор + + + +У данного репозитория 2 автора примерно одинаковой степени извращенства, поэтому сразу стоит отметить, что если вы заглядываете сюда для того чтобы получить самые простые решения - можно разворачиваться и уходить. Да и методичка впринципе написана вполне понятно + +Для тех кто остался, поясняем. Из используемого ПО: + +- Linux - почти любой дистрибутив на базе x86-64. +- Nasm - ассемблер, с которым будем работать вчистую, если потребуется +- GCC - стандартная коллекция гнушных компиляторов. Скорее всего с ней будем работать больше всего +- GDB - Классический гнушный и немного душный дебаггер. Дебажит все, но надо привыкнуть + +#### Комментарии + +Кого-то заинтересуте вопрос, почему именно такой набор: + +У Винды, Линукса и Мака есть свои особенности по части выполнения действий в ассемблере. Например отличаются таблицы системных вызовов, а также у винды гораздо шире стандартная библиотека Win32. Про мак ничего сказать не могу - не работал. Выбор пал на линукс, потому что лично мне он привычнее и у него не столь хтоническая коллекция системных вызовов. + +Выбор же ассемблера менее принципиален, просто так случилось, что под линукс работают nasm, yasm и gasm. Я предпочитаю работать с nasm, так как по нему немного больше документации и она даже продолжает поддерживаться. И пусть выбор ассемблера не принципиален, я буду по возможности работать с nasm, хотя во время вставок ассемблера в C возможно придется обратиться и к другим ассемблерам + +GCC - пойдет любой компилятор для C. gcc просто лично мне роднее. Хорошим выбором также может стать clang. + +GDB - это классический гнушный (и немного душный) дебаггер, который будет работать везде и чуть ли не со всем на планете, но как и многое из того, что написано под линукс, выглядит это как-то так: + +![Картинка с gdb](./assets/typical_gdb.PNG) + +Поэтому если вы не отчаялись, лучше поставить edb или какой-нибудь скин на GDB вроде [Voltron](https://github.com/snare/voltron). Но почему именно GDB? Ну... Я извращенец. Если вы тоже, то замечу, что у gdb есть нативный TUI, который можно вполне гибко настраивать. Почитать по этому поводу побольше можно [тут](https://www.sourceware.org/gdb/current/onlinedocs/gdb.html/TUI.html) + +### Оффтоп + +Поскольку пусть ассемблера тяжел, а мы с вами вряд ли когда-нибудь будем писать ассемблер лучше компилятора. Даже умные дяди не всегда пишут код лучше компилятора. В связи с этим предлагаю сразу же сдаться и узнать, что у GCC есть опция `-S`, которая заставит его компильнуть код до ассемблера. При этом использоваться будет Gasm. Также есть возможность воспользоваться [Compiler Explorer'ом](https://godbolt.org/). Он приятен тем, что выдает ассемблер в синтаксисе intel, а не AT&T. Хотя и это можно настроить на самом деле + +### Лабораторные работы > **Обозначения** > @@ -20,3 +69,5 @@ - [8. Отладчик](08-debugging/README.md) - [9. Обмен ЭВМ с клавиатурой](09-keyboard/README.md) - [10. Мультизадачность](10-multitasking/README.md) + + diff --git a/assets/typical_gdb.PNG b/assets/typical_gdb.PNG new file mode 100644 index 0000000..db25243 Binary files /dev/null and b/assets/typical_gdb.PNG differ