Сразу скажу - я не считаю себя втором Терри Дэвисом и тем более не хочу делать аналог Виндовс. Изначально я все это затеял только ради прикола и изучения ассемблера.

А, и если что - мне 14, но я не против любой критики. И да, я тоже как и большинство местами использовал ИИ. Я не сидел читал мануалы часами, просто гуглил или просил нейронку пояснить.

Так а в чем же проблема x86_64?

Я так скажу - я пробовал писать под эту архитектуру. Мне не понравилось, всякие режимы (которые за меня правда переключал загрузчик), да и местный ассемблер мне было лень изучать. Просто захотел писать под более новую архитектуру.

Не буду говорить, что RISC-V лучшая, но я просто выбрал ее. Прикол в том, что инструкции короткие, да и в целом достаточно перспективно. Хотя и тут были проблемы.

Был драйвер, стала ОС

Я ничего с нуля не писал.Все началось с пыток ИИ, когда я пытался выдавить из него то обращение по конкретному адресу для доступа к графике, то опрос портов, то еще что-то такое. Мне стало лень и я пошел искать что-то плюс-минус готовое. И я нашел его - ramfb. По сути я получил готовый указатель на фреймбуфер для вывода на экран… И все. Но и на этом большое спасибо авторам драйвера. Дальше началась моя ОС.

А где хранить данные?

А тут первая проблема - как таковой кучи у меня еще нету. Есть стек, который за меня выделил автор драйвера. Есть всякие глобальные переменные. Но что если мне нужно много памяти (например, под картинки) и я не знаю точный размер? И в добавок, кто вообще рисует напрямую на экран? Тут нужен некий массив пикселей, который будет лежать в памяти, а по нашей команде быстро перенесется на экран (называется backbuffer).

Под кучу взял 64 мб из памяти, так как Qemu, где запускается моя ОС, выделяет ей аж 128 мб, часть уже занята ядром и стеком, но бОльшая часть пустует. Сделал простенький список свободных и занятых блоков памяти.

Это когда ты делишь память на куски, каждый помечаешь как занятый или свободный. Нужно мало памяти - откусываем от большого куска блок. Блок освободился, а рядом есть другой свободный блок - соединяем в один большой.Сразу же добавил функцию, чтобы узнать сколько памяти занято. Сейчас, например, занято около 3-4 мб. Ну это учитывая, что backbuffer и занял почти 3.5 мб.

В оперативной памяти что-то типа

Такая разная многопоточность

Как я думаю большинство знает, если у процессора одно ядро, одновременно на нем может выполняться только одна задача-поток. Но мы же может останавливать задачу, запускать другую, останавливать, запускать еще другую и так много раз в секунду. Тогда будет казаться, будто бы у нас несколько задач выполняются одновременно.

Многопоточность кооперативная

Так мы можем сказать потокам, чтобы если один из них решит, что стоит сделать паузу, сам вызвал yield() и отдал процессор другому потоку. И я это сделал. Все что нужно было - сохранить s-регистры процессора (те, в которых лежат всякие важные значения), указатель на личный стек потока (размер стека задается при создании) и указатель на “дорогу назад” ra. То есть yield() сохраняет эту информацию потока А, затем вместо нее загружает информацию потока Б. И так по кругу.

Кстати, стеки самих потоков я выделял в той самой куче. Просто брал блок на пару кб и говорил потоку: “Это твой стек”.

Но у такого концепта есть проблема - зависает один поток, остальные перестают выполняться. Да и в целом писать yield() каждый раз сложно.

Многопоточность вытесняющая

Поэтому я и решил переписать все на вытеснение. Для начала я сделал так - каждые 100к тиков процессора сохраняются все регистры и пинается функция обработки прерываний. Таймер, по которому будет работать многопоточность - это тоже прерывание. Так же эта функция ловит ошибки по типу kernel panic. Это было сложнее - так как потоки не добровольно отдают процессор, приходится сохранять вообще все 32 регистра. Но криво-косо я написал это и функцию sleep(), во время которой функция простаивает, ее никто не трогает.

А тут еще и ИИ начал выдавать бред, пока я тестировал у меня… начинал выполняться основной код, все было хорошо, а потоки - нет. Я сам не вижу ошибку, ИИ тоже. Он то предложит заменить какую-то часть функции, то еще что-то такое. Наконец я вспомнил про замечательную штуку - gdb. Запустил, посмотрел… Оказалось так - цикл отрисовки экрана был слишком долгим, во время него вызывалось переключение потоков, а их еще не было кроме главного. В итоге я подумал что смысла создавать потоки в конце, после отрисовки, нет, и перенес их в самое начало. Удивительно, но все заработало.

Немного про режимы

Как выяснилось, в RISC-V есть 3 режима (точнее 4, включая гипервизор, но тут он мне точно не нужен) - M-mode с полными привелегиями, S-mode для ядра ОС (я думал что и мое его использует), ну и U-mode для пользователей, но до этого мои ручки еще не дошли.

Ну и по пути я случайно осознал, что мое ядро выполняется аж в М-режиме:

Вызываю я ecall из потока. Смотрю - kernel panic. В логах какой-то код “11”. Оказалось, это и есть ecall - в M-mode он 11, а в S-mode (в котором, как я думал, работало ядро, и который я пытался выловить) это 9. Ну когда я нашел, уже быстро исправил.

Визуальчик

Но в это время на сам экран эмулятора Qemu… Ничего и не выводилось. Совсем. Просто белый экран. Хотелось красоты.

Тогда я вспомнил, что день назад прикрутил qoi.h к моему коду. QOI - формат изображений. Выбрал я его, так как декодер легкий и его удобно использовать в любой ОС, где есть базовые функции.

Я аккуратно, разумеется, согласно лицензии, взял из pop os, которой когда-то пользовался, картинку для фона. Конвертировал ее в .qoi, а так как моя ос еще не умела читать с диска, перевел картинку в заголовочный файл .h. Весит правда много, но влезает.

Дальше я нашел шрифт (Liberation Mono от Red Hat), перегнал и его в .h. Честно, визуал меня не сильно интересовал, поэтому быстро попросил ИИ переделать функции вывода в консоль в функции вывода на экран. Проверил, просмотрел что и как сделано, получилось нормально для старта. Правда пока что в графической консоли нет нормальной перемотки и много чего другого.

Вывод

Конечно, еще нету даже ввода с клавиатуры, мыши, файловой системы (даже простой). Но я считаю, что вышло неплохо, пусть и далеко от уровня реальной ОС типа Линукса. Понятно, что код не очень-то красивый, достаточно простой. Статью я выкладываю больше просто чтобы разобраться самому в том, что я написал.

Если я не забью на код, хотел бы написать еще и MMU и переход в U-mode.

Для тех кому очень интересно - можете глянуть исходный код mqos, там же будут инструкции по запуску.

В своей колонке Daily Drivers редактор Hackaday Дженни Лист скачала ISO-образ, запустила KolibriOS на современном ThinkPad и удивилась: система выглядит зрелой, стабильной и по-настоящему быстрой. Разбираем, что это за проект, откуда он взялся и кому пригодится сегодня.

Что такое KolibriOS

KolibriOS — российский форк MenuetOS, созданный в 2004 году. В то время как автор оригинального MenuetOS Вилле Турьянмаа переключился на закрытую 64-битную версию, сообщество вокруг русскоязычного порта сохранило код открытым и продолжило развивать 32-битную ветку. Название «Колибри» выбрано неслучайно: система маленькая и быстрая, как птица-колибри.

Проект поддерживается преимущественно разработчиками из России, Казахстана, Украины и Германии. Код распространяется под открытой лицензией, а сборки регулярно публикуются на официальном сайте и зеркалах сообщества.

Версия 0.7.7

Версия 0.7.7 продолжает философию предельного минимализма. Минимальные системные требования смехотворны по нынешним меркам: 1 МБ места на диске, 8 МБ оперативной памяти и процессор класса i586. При этом система выдаёт графический интерфейс, многозадачность и набор встроенных программ.

Дженни Лист отмечает, что на ThinkPad 2020-х годов KolibriOS загружается «в мгновение ока» и сразу показывает рабочий стол. Интерфейс выглядит пиксельным, как в 1990-х: нет сглаживания, есть ощущение ретро. Но при этом всё работает — без синих экранов и зависаний.

• KolibriOS 0.7.7 — 32-битная ОС с ядром на ассемблере, базовый образ весит около 1 МБ.
• Минимальные требования: i586, 8 МБ ОЗУ, 1 МБ на диске.
• В комплекте браузеры, игры, эмуляторы, графические редакторы и среда разработки.
• Главное ограничение для повседневного использования — отсутствие поддержки HTTPS.
• Лучше всего подходит для старого железа, тонких клиентов, обучения и ретрокомпьютинга.

Как устроена система

Ядро на ассемблере

Большая часть KolibriOS написана на FASM — плоском ассемблере. Это объясняет крошечный размер исполняемых файлов и молниеносную загрузку: система не тратит время на инициализацию абстракций, слоёв совместимости и десятков фоновых служб.

Важная оговорка: несмотря на миф «всё на ассемблере», часть приложений и драйверов портирована или написана на C, Free Pascal, Oberon и даже Python. Но ядро, графическая подсистема и системные вызовы остаются ассемблерными.

Файловые системы и загрузка

KolibriOS умеет загружаться с CD/DVD, USB, жёстких дисков и даже с классической дискеты 1,44 МБ. Поддерживаются файловые системы FAT12/16/32, exFAT, NTFS и ext2/3/4. Есть варианты для Coreboot и загрузка прямо из Windows.

Что внутри: программы и игры

Несмотря на размер, KolibriOS поставляется с обширным набором софта. По данным сообщества, в образ входят более 250 программ, включая текстовый процессор, просмотрщик изображений, графический редактор, музыкальный плеер, IRC-клиент и веб-браузеры.

Из игр и развлечений — порты эмуляторов, DOSBox, а также shareware-версии классики вроде DOOM и Wolfenstein 3D на полноценном CD-образе. Есть поддержка SDL, что позволяет переносить проекты с «больших» систем.

Something this polished deserves a while to play around.

Главное ограничение: интернет без HTTPS

Дженни Лист называет именно этот момент решающим: встроенные браузеры KolibriOS, включая Netsurf и Webview, не поддерживают HTTPS. Без этого современный веб практически закрыт: большинство сайтов, включая сам Hackaday, просто не откроются.

Это меняет статус системы с «основной ОС на каждый день» на «платформу для специальных задач». Почта, мессенджеры, облачные сервисы и онлайн-документация остаются недоступны без промежуточного прокси или другой машины.

Почему HTTPS сложно:
Современный TLS требует большой криптографической библиотеки, регулярных обновлений корневых сертификатов и поддержки множества алгоритмов. В условиях ОС размером в мегабайт это серьёзный архитектурный вызов, который сообщество пока не взяло в штатный комплект.

Кому и где пригодится KolibriOS

С учётом ограничений у KolibriOS остаётся несколько чётких сценариев применения. В России и соседних странах это особенно актуально: парки старого офисного и школьного оборудования часто содержат машины, которые официально «не тянут» современные ОС.

• Воскрешение старого железа. Pentium- и ранние Core-машины получают рабочий стол, браузер для локальных страниц и офисные утилиты.
• Тонкие клиенты. Низкие требования к RAM и CPU делают KolibriOS кандидатом для терминалов с удалённым рабочим столом.
• Обучение. Ядро на ассемблере, простые системные вызовы и небольшой кодовой базы — отличная площадка для изучения устройства ОС.
• Ретрокомпьютинг. Запуск DOS-игр через эмулятор, классические 2D-игры и ностальгический интерфейс 1990-х.
• Встроенные системы. Сборка Kolibri-A ориентирована на специализированное железо и железные проекты.

Как попробовать KolibriOS

Попробовать систему проще всего в виртуальной машине. Скачайте ISO-образ с официального сайта, создайте VM с 64 МБ ОЗУ и загрузитесь с образа. Для реального железа подойдёт запись образа на USB-флешку или CD.

• Скачайте ISO или образ дискеты с официального сайта KolibriOS.
• Для VM: создайте 32-битную машину с 64 МБ RAM и VESA-видео.
• Для железа: запишите ISO на CD или USB через обычную утилиту.
• Загрузитесь и выберите разрешение экрана из меню загрузчика.
• Исследуйте меню «Пуск»: игры, утилиты, терминал и браузер.

Если планируете использовать сетевые функции, проверьте совместимость сетевой карты по списку оборудования. Поддерживаются многие чипы Realtek, Intel и 3Com.

Выводы

KolibriOS 0.7.7 — это не замена Windows или Linux, а демонстрация того, какой отклик может давать компьютер, когда софт пишут под железо, а не под абстракции. В эпоху, когда операционки растут гигабайтами, проект напоминает: минимализм ещё жив.

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

Главный вопрос — нужна ли вам такая система прямо сейчас. Если у вас есть старый 32-битный ноутбук, интерес к ассемблеру или просто ностальгия по быстрым ОС — попробуйте. А для повседневной работы с интернетом пока придётся держать под рукой что-то посовременнее.

Источники:

• Jenny’s Daily Drivers: KolibriOS 0.7.7 — Hackaday
• KolibriOS на DistroWatch
• Официальная вики KolibriOS

Проект опубликован на GitHub и сопровождается демонстрацией, инструкциями и, непосредственно, самим QR-изображением.

Как это работает

Это x86-код, изначально рассчитанный на DOS. Есть и вариант, который не требует BIOS, загрузчика или операционной системы.

Автор использует тонкие приемы оптимизации — минимальные инструкции, хитрые трюки с регистрами и адресацией. И все это нужно чтобы уместить игровую логику и отрисовку в крошечный набор байтов.

Зачем все это

Разумеется, это никакая не попытка заменить полноценную игру, а упражнение в минимализме: показать, как далеко можно зайти с низкоуровневыми оптимизациями.

В README автор прямо сравнивает размер в байтах с обычными программами.

Практическое значение и эстетика

Проекты вроде этого интересны двумя вещами:

1. Техническая демонстрация — они учат «компактному» мышлению и глубокому пониманию архитектуры процессора;
2. Эстетика хакерской культуры — умение поместить игру в QR-код служит чистым челленджем и поводом для обсуждений в сообществе.

Где посмотреть и запустить

Сборник кода, QR-изображение и онлайн-демо доступны на странице проекта на GitHub.

Там же — инструкции, как запустить локально (скрипты main.sh/main.bat) и как собрать свое QR-воплощение.

Проект содержит 50 000 строк ассемблерного кода, который был тщательно задокументирован и прокомментирован для понимания работы игры под капотом.

Что это за проект?

Разработчик Мара Моксон, энтузиаст и исследователь классических игр, опубликовал исходники Elite, позволив тем самым не только изучить их, но и собрать полную рабочую версию игры для Commodore 64 на современных компьютерах.

Документация включает:

• Подробные комментарии к каждой строке кода.
• Варианты сборок для NTSC и PAL версий игры.
• Пояснения к структуре файлов и использованным техникам.

Почему это важно?

Elite, впервые вышедшая в 1984 году, считается одной из величайших игр в истории, задавших стандарты для жанров космических симуляторов и открытого мира.

Для Commodore 64 игра вышла в 1985 году и использовала ассемблерный код, демонстрируя уникальные для своего времени технические решения.

Теперь разработчики, энтузиасты и любители ретро-игр могут изучить, как создавался этот шедевр, и даже создать свои модификации или порты.

Где найти код?

Исходный код доступен на GitHub. Кроме того, проект сопровождается удобным сайтом с визуализированным и более «читаемым» представлением исходников.

Этот релиз — редкая возможность заглянуть в историю и увидеть, как программисты 80-х справлялись с ограниченными ресурсами для создания одной из самых знаковых игр в индустрии.

Результаты можно посмотреть здесь. Подпишитесь на тэг Лучший язык 2022 и следите за новыми раундами в личной ленте.

Сегодня в схватке столкнутся:

• Go и Python;
• Assembler и C.

Голосование по этим языкам программирования продлится до 15 декабря 2022 года. Опросы будут закрыты в 11:00 по МСК.

Правила батла по-прежнему просты:

1. В батле участвует 16 языков программирования.
2. Ежедневно соревнуются две пары.
3. За любимый язык можно проголосовать в течение 24 часов.
4. Пары составляются рандомно, так что выбирайте язык, который субъективно нравится больше.
5. В финале мы определим тройку победителей.
6. Старт — 13 декабря, финал — 20 декабря.

Примечание Забирайте эту запись в закладки, ведь именно в неё будут добавляться ссылки на последующие этапы голосования.

• Этап 1
• Этап 2
• Этап 3
• Этап 4
• Этап 5
• Этап 6
• Полуфинал
• Финал
• Результаты

Турнирная таблица:

Старт уже завтра — 13 декабря в 11:00 МСК. Следите, участвуйте, голосуйте!

• C vs. PHP
• TypeScript vs. Assembler

Выбирайте любимый язык, исходя из личных симпатий. Голосование завершится 15 декабря 2021 года в 11:00 по Москве.

Ознакомиться с анонсом можно здесь.

Но давайте отвлечёмся от официальной статистики и узнаем, какие языки предпочитаете именно вы! Завтра стартует баттл языков программирования 2021. Правила просты:

1. Всего участвует 16 языков программирования.
2. Каждый день соревнуются две пары.
3. На возможность проголосовать за любимый язык отводится 24 часа.
4. Пары составляются рандомно.
5. Выбирайте тот язык, который субъективно нравится вам больше.
6. В финале мы определим победителей — языки которые заняли первое, второе и третье место.
7. Старт — 14 декабря, финал — 21 декабря.

Так выглядит изначальная турнирная таблица:

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

Подписывайтесь на уведомления на сайте, чтобы быть в курсе лидеров и новых голосований.

Результаты баттла можно посмотреть по ссылке.

В комментариях подсказывают, что в реальности машинный код получается более оптимизированным. По этой ссылке вы найдете компилятор из языка Си в Assembler, который подсвечивает соответствующие друг другу строки программы на С и Assembler.

0:00 Как программа на C считает числа Фибоначчи

2:28 Как скомпилировать и дизассемблировать программу

3:20 Разбор машинного кода

Сегодня соревнуются следующие две пары языков: Assembler/Pascal и С++/Cobol. Помните, что мы не сравниваем языки объективно. Выбирайте тот, что вы любите.

Голосование закончится ровно через 24 часа — 16 декабря 2020 года в 11:00 по московскому времени.

Финальное голосование — здесь.

Включите уведомления в браузере, чтобы следить за ходом голосования.

Завтра начинается баттл языков программирования 2020. Правила просты:

• В баттле участвуют 16 языков;
• ежедневно соревнуются две пары;
• на каждое голосование отводится 24 часа;
• вы выбираете язык который субъективно нравится вам больше чем его оппонент;
• пары подбираются случайно;
• в результате мы определим победителей, занявших первое, второе и третье места;
• Старт завтра — 14 декабря, финал — 21 декабря.

Так выглядит изначальная турнирная таблица:

Подписывайтесь на уведомления на сайте, чтобы быть в курсе текущих лидеров и новых голосований.

Как такое возможно?

Оказывается, сама по себе инструкция mov тьюринг-полная, а значит, с её помощью можно запрограммировать любой алгоритм, как на классических языках.

Если коротко, то суть в том, как проводить «сравнения» и затем в зависимости от результата выполнять определённую команду. Допустим, мы хотим сравнить значения A и B. Помещаем их в регистры Ri и Rj. Мы это можем сделать, у нас есть mov. Затем выполняем хитрый код:

Здесь мы интерпретируем значения Ri и Rj (т.е. A и B) как адреса и записываем в них 0 и 1. Если значения были одинаковые, то и адрес будет одинаковый, и он перезапишется. В итоге в Rk будет 1, если A=B, и 0 в другом случае. Почему нам не важно, что было по адресам Ri и Rj — читайте в подробном разборе, для нас это сейчас не имеет значения.

Затем мы можем поместить по некоторому адресу N одну инструкцию, а в следующую ячейку памяти N+1 — другую. И выполнить ту, что по адресу N+Rk. Вот мы и получили аналог условного выполнения инструкций, но используя только mov. Осталось только перевести весь код в такую форму, а в самом конце добавить безусловный переход на начало программы.

Более детально изучить, как это работает, можно по презентации, слайдам или текстовому описанию в PDF.

Зачем это нужно?

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

Для авторов M/o/Vfuscator сборка DOOM только через mov-инструкции нужна для доказательства работоспособности их метода. Работает, правда, всё очень долго — один кадр рендерится около 7 часов. Но в данном случае главное, что вообще работает.

Данный курс это авторская программа «Школы Программистов», целью которой является изложить самые базовые понятия из мира программирования в доступном и структурированном виде.

Для этого курса не нужны предварительные углублённые знания в математике или опыт программирования. Курс начинается с таких понятий, как информация в целом, затем следует часть введения в ассемблер и углубление знаний до процедур и операторов в ассемблере.

В курсе будут рассмотрены следующие темы:

• отличия микроконтроллеров от традиционных компьютеров;
• обзор популярных семейств микроконтроллеров (ARM, AVR, MSP430 и др.) , их возможностей, а также проектов на их основе;
• настройка среды разработчика и написание программ на Си и Ассемблер;
• обзор периферийных интерфейсов и протоколов;
• ввод/вывод общего назначения и подключение различных внешних устройств;
• работа с прерываниями и таймерами;
• сведения о начальной загрузке и инициализации контроллера.

Демонстрация

Компиляция функции, вычисляющей простые числа, с помощью M/o/Vfuscator в сравнении с GCC:

Язык Ассемблера

GCC

M/o/Vfuscator

Граф потока управления

GCC

M/o/Vfuscator

M/o/Vfuscator в действии

Пример поинтереснее

Сборка

M/o/Vfuscator использует LCC в качестве препроцессора. Предлагаемый скрипт сборки автоматически загружает LCC, настраивает его конфигурацию для MOV и собирает M/o/Vfuscator.

Если вы проводите сборку на 64-битной системе, убедитесь, что у вас есть доступ к 32-битной стандартной библиотеке (например, apt-get install libc6-dev-i386 или yum install glibc-devel.i686).

Тестирование

Проверьте, что сборка произошла корректно, с помощью следующего скрипта:

Использование

Компилируйте программы как обычно.

Всю остальную необходимую информацию можно найти в репозитории проекта на GitHub.

В прошлой статье я писал о том, как создать простейшее x86-ядро, использующее GRUB, работающее в защищённом режиме и выводящее на экран строку. В этот раз мы подключим к ядру драйвер клавиатуры, который может считывать символы a–z и 0–9 с клавиатуры и выводить их на экран. Весь используемый код можно найти на GitHub.

Мы общаемся с устройствами ввода / вывода, используя I/O-порты. Эти порты — просто определённые адреса на шине ввода / вывода x86-системы. Операции чтения / записи на этих портах обрабатываются специальными инструкциями, встроенными в процессор.

Чтение из портов и запись в них

Доступ к портам I/O можно получить, используя инструкции in и out, являющиеся частью набора инструкций x86.

В read_port номер порта принимается как аргумент. Когда компилятор вызывает вашу функцию, он пушит все её аргументы в стек. Аргумент копируется в регистр edx по указателю на стек. Регистр dx — это младшие 16 бит edx. Инструкция in читает из порта, номер которого хранится в dx, и помещает результат в al. Регистр al — это младшие 8 бит eax. Если вы помните, чему вас учили, то знаете, что возвращаемые функциями значения передаются через регистр eax register. Таким образом, read_port обеспечивает чтение из I/O-портов.

write_port очень похожа. Мы принимаем два аргумента: номер порта и данные для записи. Инструкция out записывает данные в указанный порт.

Прерывания

Теперь, прежде чем мы продолжим писать какой-либо драйвер устройства, давайте разберемся, как процессор узнаёт о том, что устройство совершило действие.

Самое простое решение — это поллинг, постоянная проверка состояния устройства. По очевидным причинам это не самое практичное решение. Тут в дело вступают прерывания. Прерывание — это сигнал, посылаемый процессору аппаратным или системным обеспечением, который оповещает о событии. Используя прерывания, мы можем действовать только тогда, когда возникает интересующее нас прерывание.

Устройство, называемое контроллером прерываний (Programmable Interrupt Controller, PIC), отвечает за обработку аппаратных прерываний и отправку их соответствующим системным прерываниям.

Когда на аппаратном обеспечении происходит какое-то событие, оно отправляет сигнал, называемый запросом прерывания, по свому специальному каналу на контроллер прерываний. Контроллер преобразует запрос в системное прерывание и отправляет его в процессор, где им занимается ядро.

Если бы у нас не было контроллера прерываний, то нам пришлось бы постоянно опрашивать все устройства на наличие произошедших событий.

Рассмотрим случай с клавиатурой. Она работает через I/O-порты 0x60 и 0x64. Порт 0x60 передаёт данные (о нажатой клавише), а порт 0x64 — состояние. Однако нужно знать наверняка, когда и из какого порта читать данные.

Для этого отлично подходят прерывания. Когда происходит нажатие клавиши, клавиатура посылает сигнал на контроллер прерываний по линии IRQ1. Контроллер обладает значением offset, полученным во время его инициализации. Он добавляет номер входной линии к этому offset и получает число прерывания. Затем процессор обращается к специальной структуре данных, называющейся дескрипторной таблицей прерываний (Interrupt Descriptor Table, IDT), для передачи обработчику прерываний адреса, соответствующего числу прерывания.

После этого запускается код, расположенный по этому адресу, и обрабатывает исключение.

Настраиваем IDT

Мы реализуем IDT как массив структур IDT_entry. Мы обсудим то, как прерывание клавиатуры привязано к своему обработчику, позже. Сперва посмотрим, как работают контроллеры прерываний.

Современные x86-системы имеют два контроллера прерываний по 8 входных линий. Назовём их PIC1 и PIC2. PIC1 получает сигналы с IRQ0 до IRQ7, а PIC2 — с IRQ8 до IRQ15. PIC1 использует порт 0x20 для команд и 0x21 — для данных. PIC2 использует порт 0xA0 для команд и 0xA1 — для данных.

Контроллеры инициализируются 8-битными инициализирующими командными словами (Initialization command words, ICW). Подробный синтаксис этих команд можно изучить здесь.

В защищённом режиме первой командой, которую вы должны передать двум контроллерам прерываний, является инициализирующая команда ICW1 (0x11). Эта команда заставляет контроллер ждать поступления ещё трёх инициализирующих слов на порт данных.

Эти команды сообщают контроллерам следующее:

• сдвиг (ICW2);
• состояние подключения (master/slave) (ICW3);
• дополнительную информацию об окружении (ICW4).

Вторая инициализирующая команда — это ICW2, которая записывает в порты данных каждого контроллера его сдвиг.

Контроллеры допускают каскадирование выводов и вводов, что настраивается командой ICW3, но мы не будем его использовать, поэтому установим все значения в ноль.

ICW4 устанавливает дополнительные параметры окружения. Мы  заполним младший бит, чтобы сказать контроллерам, что мы работаем в режиме 80×86.

Та-дам! Контроллеры прерываний инициализированы!

У каждого контроллера есть внутренний 8-битный регистр, называющийся регистр масок прерывания (Interrupt Mask Register, IMR). Этот регистр хранит битмэп линий IRQ, идущих в контроллер. Если бит установлен, контроллер игнорирует запрос. Это означает, что мы можем включать и выключать любую линию IRQ, меняя соответствующее значение в IMR. Чтение из порта данных возвращает значение из IMR, а запись — задаёт это значение. В нашем коде мы отключаем все линии IRQ, чтобы позже включить ту, что соответствует клавиатуре.

Если линии IRQ включены, наши контроллеры могут получать идущие по ним сигналы и преобразовывать их в числа прерываний, добавляя сдвиг. Теперь нам нужно найти IDT такую, чтобы число прерывания для клавиатуры было привязано к адресу обработчика событий клавиатуры, который мы напишем.

Какое число прерывания должно соответствовать обработчику событий клавиатуры?

Клавиатура использует IRQ1. Это линия ввода 1 контроллера PIC1. Его сдвиг равен 0x20. Для получения числа прерывания сложим 1 + 0x20 и получим 0x21. Таким образом, адрес обработчика событий должен быть связан с прерыванием 0x21 в IDT.

Теперь нам нужно определить IDT для прерывания 0x21. Мы привяжем это прерывание к функции keyboard_handler, которую запишем в ассемблерном файле.

Каждое значение в IDT состоит из 64 битов. В значении IDT для прерывания мы не храним адрес функции-обработчика целиком, а делим его на 2 части по 16 бит. Младшие биты хранятся в первых 16 битах значения IDT, а старшие 16 битов — в последних. Это сделано в целях совместимости с 286. Да, такие костыли от Intel можно встретить часто!

В значении IDT мы также должны задать тип — это нужно для того, чтобы поймать исключение. Нам также нужно передать коду ядра смещение. GRUB создаст для нас глобальную таблицу дескрипторов, каждое значение которое занимает 8 байт. Дескриптор кода ядра — это второй сегмент, поэтому его сдвиг равен 0x08. Окно прерывания равно 0x8e. Оставшиеся посередине 8 бит должны быть заполнены нулями. Таким образом, мы заполнили значение IDT в соответствии с прерыванием клавиатуры.

После того, как мы закончили все махинации с IDT, мы сообщаем процессору её адрес, используя инструкцию lidt, принимающую один операнд, который должен быть указателем на структуру дескрипторов, описывающую IDT.

Дескриптор достаточно прост. Он содержит размер IDT в байтах и её адрес. Для хранения значений я использовал массив, но вы можете воспользоваться структурой.

У нас есть указатель в переменной idt_ptr, который мы передаём в lidt, используя функцию load_idt().

Кроме того, функция load_idt() включает прерывания, используя инструкцию sti.

Когда IDT настроена, мы можем включить линию IRQ клавиатуры, используя маску прерываний, о которой мы говорили ранее.

Функция обработки прерываний клавиатуры

Итак, наши прерывания клавиатуры привязаны к функции keyboard_handler через значение IDT для прерывания 0x21. Каждый раз, когда мы нажимаем клавишу, мы можем быть уверены, что функция будет вызвана.

Эта функция просто вызывает другую функцию, написанную на Си, и возвращает значение, используя класс инструкций iret. Мы могли бы написать здесь весь необходимый код, но на Си писать безусловно приятнее. iret/iretd используются вместо ret при работе с прерываниями.

Сперва мы отправляем сигнал EOI (конец прерывания), записывая его в порт команд контроллера. Только после этого контроллер принимает следующие прерывания. Нам нужно читать два порта — порт данных 0x60 и порт команд / данных 0x64.

Сперва мы читаем порт 0x64 для получения состояния. Если младший бит состояния равен 0, то буфер пуст, и данных для чтения нет. В обратном случае мы читаем порт данных 0x60. Этот порт даёт нам код каждой нажатой клавиши. Мы используем простой массив символов в файле keyboard_map.h для связывания кодов и символов.

В этой статье мы обрабатываем только строчные буквы и цифры. Конечно, можно настроить и обработку других клавиш, а также их сочетаний.

Вы можете собрать ядро и запустить его на реальной машине или в эмуляторе (QEMU) так же, как и в прошлой статье.

Печатайте!

Давайте напишем простое ядро, которое можно загрузить при помощи бутлоадера GRUB x86-системы. Это ядро будет отображать сообщение на экране и ждать.

Как загружается x86-система?

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

В большей части регистров процессора при запуске уже находятся определённые значения. Регистр, указывающий на адрес инструкций (Instruction Pointer, EIP), хранит в себе адрес памяти, по которому лежит исполняемая процессором инструкция. EIP по умолчанию равен 0xFFFFFFF0. Таким образом, x86-процессоры на аппаратном уровне начинают работу с адреса 0xFFFFFFF0. На самом деле это — последние 16 байт 32-битного адресного пространства. Этот адрес называется вектором перезагрузки (reset vector).

Теперь карта памяти чипсета гарантирует, что 0xFFFFFFF0 принадлежит определённой части BIOS, не RAM. В это время BIOS копирует себя в RAM для более быстрого доступа. Адрес 0xFFFFFFF0 будет содержать лишь инструкцию перехода на адрес в памяти, где хранится копия BIOS.

Так начинается исполнение кода BIOS. Сперва BIOS ищет устройство, с которого можно загрузиться, в предустановленном порядке. Ищется магическое число, определяющее, является ли устройство загрузочным  (511-ый и 512-ый байты первого сектора должны равняться 0xAA55).

Когда BIOS находит загрузочное устройство, она копирует содержимое первого сектора устройства в RAM, начиная с физического адреса 0x7c00; затем переходит на адрес и исполняет загруженный код. Этот код называется бутлоадером.

Бутлоадер загружает ядро по физическому адресу 0x100000. Этот адрес используется как стартовый во всех больших ядрах на x86-системах.

Все x86-процессоры начинают работу в простом 16-битном режиме, называющимся реальным режимом. Бутлоадер GRUB переключает режим в 32-битный защищённый режим, устанавливая нижний бит регистра CR0 в 1. Таким образом, ядро загружается в 32-битном защищённом режиме.

Заметьте, что в случае с ядром Linux GRUB видит протоколы загрузки Linux и загружает ядро в реальном режиме. Ядро самостоятельно переключается в защищённый режим.

Что нам нужно?

• x86-компьютер;
• Linux;
• ассемблер NASM;
• gcc;
• ld (GNU Linker);
• grub;

Исходники можно найти на GitHub.

Задаём точку входа на ассемблере

Как бы не хотелось ограничиться одним Си, что-то придётся писать на ассемблере. Мы напишем на нём небольшой файл, который будет служить исходной точкой для нашего ядра. Всё, что он будет делать — вызывать внешнюю функцию, написанную на Си, и останавливать поток программы.

Как же нам сделать так, чтобы этот код обязательно был именно исходной точкой?

Мы будем использовать скрипт-линковщик, который соединяет объектные файлы для создания конечного исполняемого файла. В этом скрипте мы явно укажем, что хотим загрузить данные по адресу 0x100000.

Вот код на ассемблере:

Первая инструкция, bits 32, не является x86-ассемблерной инструкцией. Это директива ассемблеру NASM, задающая генерацию кода для процессора, работающего в 32-битном режиме. В нашем случае это не обязательно, но вообще полезно.

Со второй строки начинается секция с кодом.

global — это ещё одна директива NASM, делающая символы исходного кода глобальными. Таким образом, линковщик знает, где находится символ start — наша точка входа.

kmain — это функция, которая будет определена в файле kernel.c. extern значит, что функция объявлена где-то в другом месте.

Затем идёт функция start, вызывающая функцию kmain и останавливающая процессор инструкцией hlt. Именно поэтому мы заранее отключаем прерывания инструкцией cli.

В идеале нам нужно выделить немного памяти и указать на неё указателем стека (esp). Однако, похоже, что GRUB уже сделал это за нас. Тем не менее, вы всё равно выделим немного места в секции BSS и переместим на её начало указатель стека. Мы используем инструкцию resb, которая резервирует указанное число байт. Сразу перед вызовом kmain указатель стека (esp) устанавливается на нужное место инструкцией mov.

Ядро на Си

В kernel.asm мы совершили вызов функции kmain(). Таким образом, наш “сишный” код должен начать исполнение с kmain():

Всё, что сделает наше ядро — очистит экран и выведет строку “my first kernel”.

Сперва мы создаём указатель vidptr, который указывает на адрес 0xb8000. С этого адреса в защищённом режиме начинается “видеопамять”. Для вывода текста на экран мы резервируем 25 строк по 80 ASCII-символов, начиная с 0xb8000.

Каждый символ отображается не привычными 8 битами, а 16. В первом байте хранится сам символ, а во втором — attribute-byte. Он описывает форматирование символа, например, его цвет.

Для вывода символа s зелёного цвета на чёрном фоне мы запишем этот символ в первый байт и значение 0x02 во второй. 0 означает чёрный фон, 2 — зелёный цвет текста.

Вот таблица цветов:

В нашем ядре мы будем использовать светло-серый текст на чёрном фоне, поэтому наш байт-атрибут будет иметь значение 0x07.

В первом цикле программа выводит пустой символ по всей зоне 80×25. Это очистит экран. В следующем цикле в “видеопамять” записываются символы из нуль-терминированной строки “my first kernel” с байтом-атрибутом, равным 0x07. Это выведет строку на экран.

Связующая часть

Мы должны собрать kernel.asm в объектный файл, используя NASM; затем при помощи GCC скомпилировать kernel.c в ещё один объектный файл. Затем их нужно присоединить к исполняемому загрузочному ядру.

Для этого мы будем использовать связывающий скрипт, который передаётся ld в качестве аргумента.

Сперва мы зададим формат вывода как 32-битный Executable and Linkable Format (ELF). ELF — это стандарный формат бинарных файлов Unix-систем архитектуры x86. ENTRY принимает один аргумент, определяющий имя символа, являющегося точкой входа. SECTIONS — это самая важная часть. В ней определяется разметка нашего исполняемого файла. Мы определяем, как должны соединяться разные секции и где их разместить.

В скобках после SECTIONS точка (.) отображает счётчик положения, по умолчанию равный 0x0. Его можно изменить, что мы и делаем.

Смотрим на следующую строку: .text : { *(.text) }. Звёздочка (*) — это специальный символ, совпадающий с любым именем файла. Выражение *(.text) означает все секции .text из всех входных файлов.

Таким образом, линковщик соединяет все секции кода объектных файлов в одну секцию исполняемого файла по адресу в счётчике положения (0x100000). После этого значение счётчика станет равным 0x100000 + размер полученной секции.

Аналогично всё происходит и с другим секциями.

Grub и Multiboot

Теперь все файлы готовы к созданию ядра. Но остался ещё один шаг.

Существует стандарт загрузки x86-ядер с использованием бутлоадера, называющийся Multiboot specification. GRUB загрузит наше ядро, только если оно удовлетворяет этим спецификациям.

Следуя им, ядро должно содержать заголовок в своих первых 8 килобайтах. Кроме того, этот заголовок должен содержать 3 поля, являющихся 4 байтами:

• магическое поле: содержит магическое число 0x1BADB002 для идентификации ядра.
• поле flags: нам оно не нужно, установим в ноль.
• поле checksum: если сложить его с предыдущими двумя, должен получиться ноль.

Наш kernel.asm станет таким:

Строим ядро

Теперь мы создадим объектные файлы из kernel.asm и kernel.c и свяжем их, используя наш скрипт.

Эта строка запустит ассемблер для создания объектного файла kasm.o в формате ELF-32.

Опция “-c” гарантирует, что после компиляции не произойдёт скрытого линкования.

Это запустит линковщик с нашим скриптом и создаст исполняемый файл, называющийся kernel.

Настраиваем grub и запускаем ядро

GRUB требует, чтобы имя ядра удовлетворяло шаблону kernel-<version>. Поэтому переименуйте ядро. Своё я назвал kernel-701.

Теперь поместите его в директорию /boot. Для этого понадобятся права суперпользователя.

В конфигурационном файле GRUB grub.cfg добавьте следующее:

Не забудьте убрать директиву hiddenmenu, если она есть.

Перезагрузите компьютер, и вы увидите список ядер с вашим в том числе. Выберите его, и вы увидите:

Это ваше ядро! В следующей части добавим систему ввода / вывода.

P.S.

• Для любых фокусов с ядром лучше использовать виртуальную машину.
• Для запуска ядра в grub2 конфиг должен выглядеть так:menuentry 'kernel 7001' {tset root='hd0,msdos1'tmultiboot /boot/kernel-7001 ro}
• если вы хотите использовать эмулятор qemu, используйте:qemu-system-i386 -kernel kernel

MBR — раздел, содержащий код и данные, необходимые для последующей загрузки операционной системы и расположенные в первых физических секторах. Самые первые 446 байт диска отдаются под код загрузчика. Именно в это место и записывается TetrOS.

Естественно, из-за таких свойств он загружается перед любой операционной системой — никакой ОС ему не требуется, он работает сам. Да-да, вы не ослышались, TetrOS — сам себе загрузчик.

Вот так это выглядит на экране:

А исходник на загрузочном секторе выглядит так:

И да, это весь исходник. Вы же помните, что он весит всего 446 байт?

Можно запустить эту «чудо-операционную систему» под qemu или даже по-настоящему установить на загрузочный раздел диска или флешки.

Запуск

qemu

Просто установите qemu:

sudo apt-get install qemu

и запустите:

make run

Загрузка на флешку

Скопируйте образ на флешку. Допустим, если флешка подмонтирована как /dev/sde, вам понадобится выполнить следующую команду, чтобы записать на ее загрузочный сектор TetrOS:

sudo dd if=tetros.img of=/dev/sde

Описание игры

Разработчик сумел всего в 512 байт памяти впихнуть не самый скучный дизайн. У каждого кирпичика в игре есть свой цвет, управление производится кнопками, в случае поражения игра завершается, кирпичики генерируются случайным образом… BolgenOS и рядом не стояла!

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

Игра написана на nasm, и ее можно собрать самостоятельно. Устанавливаем nasm:

sudo apt-get install nasm

Собираем с помощью команды make. На выходе вы получите файл tetros.img.

Аналоги

Это не единственный проект, умещающий какую-либо классическую игру в один загрузочный сектор. Вот, например:

• Bootris
• Tetranglix
• BootChess
• Tetrasm

Разработка ведётся на Linux, весь исходный код доступен на GitHub. В первых двух статьях автор использует ассемблер для написания ядра, после этого — Rust.

Статьи написаны простым, понятным даже начинающим программистам языком, все термины либо объясняются в статье, либо снабжены ссылками на другие Интернет-ресурсы.

Реализация этого проекта однозначно будет вам полезна: во-первых, вы сможете освоить или подтянуть знания по используемым в нём языкам программирования, а во-вторых, разберётесь в основных принципах работы операционной системы.

Итак, вот список статей:

1. Пишем простое x86-ядро.
2. Переход в 64-битный режим.
3. Настройка Rust.
4. Настройка интерфейса вывода.
5. Аллокатор фреймов.
6. Таблицы страниц.
7. «Ремап» ядра.
8. Куча.
9. Обработка исключений.
10. Сообщения об исключениях.
11. Возврат из исключений.
12. Двойные ошибки (ошибки исключений).

Серия продолжает пополняться, поэтому периодически сюда заглядывайте, мы будем дополнять вышеуказанный список.

Здравствуйте! Хочу немного рассказать о разработке проекта SASM — среды разработки для языков ассемблера.

Чтобы сразу было понятно о чём речь:
Сайт: http://dman95.github.io/SASM/
Репозиторий с кодом на GitHub: https://github.com/Dman95/SASM

Что это?

SASM — простая кроссплатформенная (доступна на Windows и Linux, люди собирали и под Mac) среда разработки для языков ассемблера NASM, MASM, GAS, FASM с подсветкой синтаксиса и отладчиком. Программа работает «из коробки» и хорошо подойдет для начинающих изучение языка ассемблера. Основана на Qt. Распространяется по свободной лицензии GNU GPL v3.0.

Идея

На 1 курсе в моём университете проходил учебный курс «Архитектура и язык ассемблера», в котором мы изучали ассемблер NASM и сдавали задачи на нем в ejudge контестах. Привыкший к использованию IDE при программировании до этого, я был не очень рад собирать все в командной строке. Удобных на мой взгляд IDE для NASM не было. Универсальные решения типа Geany мне не очень нравились. Да и хотелось уже сделать что-нибудь большое и заодно выучить C++.
Итак, было решено написать свою IDE для NASM, в первую очередь для себя и может быть однокурсников.

Реализация

Опыта написания GUI у меня до этого не было, да и C++ я на тот момент не знал (в 1 семестре у нас был C). Решил всему учиться сразу при написании проекта. Много слышал про фреймворк Qt и написание на нем приложений с графическим пользовательским интерфейсом. Его и было решено выбрать для проекта.

Qt — бесплатный кроссплатформенный фреймворк, да и достаточно популярный, что немаловажно при изучении. К тому же в комплекте с ним идет очень удобная среда разработки Qt Creator и замечательная справка Qt Assistant (однако только на английском).

Первые шаги

В первый день почитал немного лекций 2 курса по C++. Затем, так как хотелось побыстрее начать, прочитал первые 100 страниц книги Бланшета, Саммерфилда «Программирование GUI на C++» о программировании с использованием Qt.

Сначала был написан просто текстовый редактор с логом построения и окнами ввода/вывода. Программа умела собирать код, который был в текстовом редакторе и запускать построенную программу, передавая ей ввод и получая её вывод (и для сборки, и для запуска использовались QProcess).

Подсветка синтаксиса

«Какая же IDE может быть без подсветки?» — подумал я и решил прикрутить оную. Qt — очень богатый фреймворк, и даже для этой, с виду не такой распространенной задачи, там было решение — QSyntaxHighlighter. Нужно было только отнаследоваться от него и заимплементить функцию highlightBlock, которая будет вызываться автоматически, когда нужно. Функция подсвечивала синтаксис, проходя по списку пар <регулярное выражение QRegExp, необходимый формат текста (цвет, курсив и т.д.)>. Про регулярные выражения узнал опять же из Qt Assistant — очень удобная вещь, с тех пор применял их не в одной задаче.

Отладчик

По ходу дела я выкладывал первые версии на обозрение однокурсников и получал некоторый фидбек. Одной из самых востребованных и интересных фич был отладчик. И на самом деле, в начале, при написании программ на языке ассемблера, было где наделать ошибок. К тому же для более полного понимания интересно было посмотреть результаты работы отдельных команд (как меняются регистры, как выставляются флаги). Отладчик очень бы помог в этих случаях.

Решено было использовать стандартный консольный GDB, опять же запуская его через QProcess, на вход подавать нужные команды, соответствующие действиям пользователя в интерфейсе, и разбирая теми же регулярками его вывод.

Там были свои заморочки, связанные с дебагом именно кода, который получается из программы на языке ассемблера. Это происходило из-за того, что ассемблер NASM не добавлял полной отладочной информации в исполняемый файл (только информацию по функциям и переменным). Приходилось разбирать его листинги, чтобы, например, понять в каком месте в тексте программы мы сейчас находимся (GDB говорил только место в памяти).

Так или иначе, отладчик был реализован — можно было ходить по программе, ставить брейкпоинты, через некоторое время добавил показ регистров и памяти.

Ещё фичи

Перевел программу на русский — в приложениях на Qt хороший тон не использовать в коде отличный от английского язык. С помощью Qt это делается очень просто: все строки, которые нужно переводить, заключаются в функцию tr (например, tr(“string to translate”)). Затем Qt Linguist парсит все такие упоминания строк и позволяет перевести их и сохранить в файл с переводом. Этот файл загружается в программе при выборе другого языка.

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

В программу была включена библиотека макросов ввода/вывода io.inc для NASM (она была взята из курса «Архитектура и язык ассемблера» и немного изменена для правильной работы с отладчиком, а также была написана ее x64 версия). Она очень удобна для новичков: когда не знаешь соглашения о вызовах и не можешь вызвать printf, очень удобно вызвать макрос из этой библиотеки. Описание макросов библиотеки находится на сайте программы.

Летом 2014 добавил поддержку x64 и ассемблеров MASM, FASM, GAS (все по аналогии с NASM). Для поддержки нескольких ассемблеров выделил интерфейс Assembler — добавлять новые ассемблеры стало проще.

Распространение

Проект где-то в середине своего пути был залит на GitHub. На GitHub Pages были сделаны русская и английская версии сайта.

Размещал сообщения о программе на русскоязычных и иностранных форумах, связанных с программированием на языке ассемблера.

Летом 2014 написал статью о программе на хабр. Сейчас мне написали из «Типичного программиста» и я сделал эту статью для вас.

Программа используется в моём университете в рамках курса «Архитектура ЭВМ и язык ассемблера». Также, судя по письмам, SASM используется и в других университетах и колледжах в России и за рубежом. Сайт программы посещает в среднем 100 человек в день.

Заключение

Опять же замечу, что проект этот OpenSource. Следовательно, любой желающий может присоединиться к разработке и сделать pull request на GitHub. Ну и конечно, можете сообщать о пожеланиях и ошибках в GitHub Issues или на мою почту Dman1095@gmail.com.