2024-09-18 21:35:54 +03:00
2024-09-07 11:15:06 +03:00
2024-09-07 11:15:06 +03:00
2024-09-07 11:15:06 +03:00
2024-09-07 11:15:06 +03:00
2024-09-07 11:15:06 +03:00
2024-09-07 11:15:06 +03:00
2024-09-07 11:15:06 +03:00
2024-09-07 11:15:06 +03:00
2024-09-07 11:15:06 +03:00

Архитектура ЭВМ

Лабораторный практикум

Что здесь находится

В данном репозитории находятся "отчеты" к лабам - авторское описание порядка действий для решения лабы. Все, что не является исходником программы будет лежать в формате .md файла.

Используемое ПО

Стандартный набор

Если вы находитесь под крылышком у Милицына, то вам нужен следующий набор:

  • Windows XP: операционная система. Есть готовый образ (WinXPCompArch.ova, 1.8 GB) для VirtualBox со всем необходимым софтом
  • Borland C for DOS - лежит в каталоге BIN папки BORLAND под названием BC
  • Turbo Debugger - Можно вызвать из-под Borland C for DOS при помощи нажатия на зачем-то оставшуюся там букву Ё.

Авторский набор

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

Для тех кто остался, поясняем. Из используемого ПО:

  • Linux - почти любой дистрибутив на базе x86-64.
  • Nasm - ассемблер, с которым будем работать вчистую, если потребуется
  • GCC - стандартная коллекция гнушных компиляторов. Скорее всего с ней будем работать больше всего
  • GDB - Классический гнушный и немного душный дебаггер. Дебажит все, но надо привыкнуть

Комментарии

Кого-то заинтересует вопрос - а почему именно такой набор:

У Винды, Линукса и Мака есть свои особенности по части выполнения действий в ассемблере. Например, отличаются таблицы системных вызовов, а также у винды гораздо шире стандартная библиотека Win32. На маках - свои решения, например Core Foundation для низкоуровневой разработки на C, помимо которого поддерживается POSIX (Unix же). Выбор пал на линукс, потому что лично мне он привычнее и у него не столь хтоническая коллекция системных вызовов.

Выбор же ассемблера менее принципиален, просто так случилось, что под линукс работают nasm, yasm и gasm. Я предпочитаю работать с nasm, так как по нему немного больше документации и она даже продолжает поддерживаться. И пусть выбор ассемблера не принципиален, я буду по возможности работать с nasm, хотя во время вставок ассемблера в C возможно придется обратиться и к другим ассемблерам

GCC - пойдет любой компилятор для C. gcc просто лично мне роднее. Хорошим выбором также может стать clang.

GDB - это классический гнушный (и немного душный) дебаггер, который будет работать везде и чуть ли не со всем на планете, но как и многое из того, что написано под линукс, выглядит это как-то так:

Картинка с gdb

Поэтому если вы не отчаялись, лучше поставить edb или какой-нибудь скин на GDB вроде Voltron. Но почему именно GDB? Ну... Я извращенец. Если вы тоже, то замечу, что у gdb есть нативный TUI, который можно вполне гибко настраивать. Почитать по этому поводу побольше можно тут

Оффтоп

Поскольку путь ассемблера тяжел, а мы с вами вряд ли когда-нибудь будем писать ассемблер лучше компилятора. Даже умные дяди не всегда пишут код лучше компилятора. В связи с этим предлагаю сразу же сдаться и узнать, что у GCC есть опция -S, которая заставит его компильнуть код до ассемблера. При этом использоваться будет Gasm. Также есть возможность воспользоваться Compiler Explorer'ом. Он приятен тем, что выдает ассемблер в синтаксисе Intel, а не AT&T. Хотя и это можно настроить на самом деле

Материалы

Лабораторные работы

Обозначения

🟢 - Готово

🟠 - WIP

Description
No description provided
Readme 510 KiB
Languages
Assembly 88.2%
C 6.6%
Python 3.1%
Makefile 2.1%