Планировщик — мозг операционной системы. Его задача: решать, какая задача выполняется сейчас, и по каким правилам выдавать процессор другим задачам. Для embedded систем это особенно критично: ресурсы ограничены, реальное время важно, а поведение должно быть предсказуемым.
Это вторая из цикла статей про создание микроядерной операционной системы. В прошлой статье рассматривался таймер и HAL. Для вновь пришедших необходимо сначала ознакомиться с ней: https://habr.com/ru/articles/935058/
Последние несколько вечеров я занимаюсь написанием простенькой операционной системы с микроядерной архитектурой. Зная, что такое занятие имеет не только исследовательский смысл, но и может стать кому то темой для курсовой или дипломной работы, я решил поделиться матчастью и показать, как всё устроено. OSdev был и остаётся высшим пилотажем в мире программирования, и я готов помочь.
Устаревшие технологии не исчезают. Они просто уходят в подполье: в архивы, на дискеты, в память тех, кто помнит, как это было. DOS-игры не просто программы. Это произведения инженерного искусства, созданные в эпоху, когда каждый байт имел значение, а каждый такт процессора, вес. Они работали на железе, которое сегодня кажется примитивным, но при этом умели то, что многим современным системам не под силу: дышать.
Моя первая игра была на дискете. Она называлась Syndicate (1993, Bullfrog Productions), и я не понимал, как она работает. Я видел, как агенты стреляют, как взрываются здания, как звучит саундтрек, но не имел ни малейшего представления, что за этим стоит.
Я знал C. Я знал, что такое переменные, циклы, указатели. Но я не мог объяснить, как в игре реализован путь юнита, как обрабатывается урон, как генерируется уровень. Тогда я не понимал кода, но код уже управлял мной.
Спустя годы я вернулся к этим играм не как игрок, а как исследователь. И понял: они — лучшая школа программирования, которую только можно себе представить.
Современные игры скрывают свою архитектуру за слоями абстракций: виртуальные машины, движки, фреймворки. Чтобы понять, как они работают, нужно разобраться в десятках технологий.
DOS-игры - другое дело: нет виртуальных машин; нет сборщиков мусора; нет драйверов. Есть только процессор, память и код, написанный на C/C++ или ассемблере. Это делает их идеальной школой для изучения реального программирования.
Дизассемблирование таких игр — это не про взлом. Это археология программирования: вы не ломаете систему, а восстанавливаете её логику по обломкам машинного кода, как археолог, собирающий мозаику из черепков.
Как-то раз я послушал следующее интересное выступление (по-немецки): ссылка
В нём разобрано, как написать программу «hello world» для 64-разрядного дистрибутива Linux в шестнадцатеричном редакторе. Ассемблер здесь не используется, программа пишется непосредственно на машинном коде. Правда, в ней есть издержки на использование ELF.
Мне понравилась такая идея, и я решил повторить такой опыт, но немного в иной форме — а именно под 16-разрядной DOS в реальном режиме. У меня должен был получиться файл в формате COM, а не EXE, так как (на данном этапе) меня интересовал не столько формат файла, сколько кодировка инструкций. В вышеупомянутой лекции, если честно, не сообщается почти никаких подробностей о том, как именно перейти от ассемблерного кода к машинному — поскольку в случае разбора этих тем лекция, пожалуй, растянулась бы на несколько часов. Но здесь я всё разберу подробно, и при этом собираюсь пользоваться только документацией lntel, а также дизассемблировать код в целях верификации.
Также мы коротко поговорим о сегментации.
В качестве шестнадцатеричного редактора на этот раз воспользуемся hexedit.
Данная статья направлена на повышение уровня понимания принципов работы барьеров памяти, которые лежат в основе атомарных операций. Она не описывает историю и первопричины появления данного механизма, а служит объяснением основных подходов.
Идеей было донести простыми словами и примерами механизмов работы барьеров памяти, поэтому в данной статье нет углубления в синтаксис ассемблер команд или архитектур процессоров.
Давным-давно, когда F11 и F12 еще не придумали, F1-F10 располагались слева, Ctrl жил на месте CapsLock, а IBM продавала компьютеры с гарантией на 90 дней, владельцы компьютеров работали в MS-DOS. Процессор еще не знал, что такое защищенный режим, память не делилась на области пользователя и ядра, виртуальной памяти не было, как не было и многозадачности. MS-DOS программа на счет "раз" нарушала работу ядра и компьютер приходилось перезагружать. Программы скромно умещались в 64 Кб, а, если превышали это ограничение, жизнь их становилась труднее.
Дизассемблируем 16-битную программу: InDuLgEo V3-B горит пламенем на экране, печатает текст и трезвонит, как старый телефон.
Большинство компиляторов — это монолитные черные ящики, унаследованные из прошлого. Мы отвергли этот путь. Мы разбираем архитектуру x86_64 до "первых принципов", чтобы понять, как на самом деле работает кремний. В этой статье мы вскрываем капот нашего компилятора ZGEN и его "фабрики машинного кода" — hwm. Никакой магии. Только чистая, детерминированная инженерия, которая превращает ассемблер в исполняемые биты.
Дарова! Сегодня я поделюсь с вами опытом, как я пытался написать собственную ОС и, что из этого вышло. Запасайтесь чайком с печеньками и присаживайтесь поудобнее! Пора окунуться в 16ти битный мир...
Мы не просто пишем код. Мы строим компиляторы, которые строят код. AsmX G3 — это не обновление, это переосмысление с первых принципов. Приготовьтесь к глубокому техническому погружению в архитектуру нашего нового компилятора ZGEN, где мы вскроем каждый компонент, от ядра до сборщика ELF, и покажем инженерные решения, которые определяют будущее системного программирования.
Это моя пятая попытка диалога с сообществом. Четыре предыдущие закончились баном. Но это не жалоба. Это деконструкция системы, которая наказывает за отклонение от нормы. Мы разберем, почему «низкий технический уровень» стал оружием конформизма и как продолжать строить, когда твой проект — системная аномалия.
Прежде чем технология изменит мир, она проходит через тысячи часов испытаний в лаборатории. Мы открываем двери нашего R&D отдела и показываем, над чем инженеры AsmX Foundation работают прямо сейчас. Улучшенная диагностика ошибок, новый синтаксис и первые шаги к полноценным вызовам библиотечных функций. Загляните в будущее компилятора.
Привет, читатель! Ты видишь это лицо и надпись "I ALWAYS COME BACK"? Это не просто мем для хайпа — это моё обещание. И я его сдержал.
Я вернулся, чтобы анонсировать AsmX G3 — новое поколение моего проекта, которое вот-вот перевернёт твоё представление о низкоуровневом программировании. Это событие, частью которого я хочу тебя видеть.
Как оптимизировать модель Mamba для выполнения на CPU? Ускоряем код в 20 раз по сравнению с PyTorch, нарушая в процессе все правила оптимизации.
🚨 Что такое Hard Fault простыми словами
Hard Fault — это критическая ошибка процессора.
Проще говоря, это ситуация, когда микроконтроллер встречает что-то настолько «невозможное» для себя, что не может продолжить выполнение программы.
Типичный пример — попытка обратиться к памяти, которой не существует, или выполнение запрещённой инструкции.
Когда это происходит, процессор сразу передаёт управление специальному обработчику — Hard Fault Handler.
Недавно залез в ROM оригинального Power Macintosh G3 и случайно обнаружил там пасхалку, о которой до этого ещё нигде не писали.
Началось с того, что одним воскресным утром я решил заглянуть в файл-шаблон ROM для Mac с помощью программы HEX Fiend Эрика Хармана. Меня интересовало, какие ресурсы хранятся в постоянной памяти Power Mac G3. Эта ROM использовалась в моделях Beige, Mini Tower и всех G3, выпускавшихся с 1997 по 1999 годы.
Пишу я эту статью в середине 2025, и мне не верится, что сегодня Power Mac G3 уже больше 27 лет. Невероятно!
В Deckhouse Prom++ мы переписали ядро хранения и обработки горячих данных на C++, при этом вся оркестрация и периферия остались в Prometheus на Go, что позволило сохранить полную совместимость с Prometheus. Для частых вызовов кода C++ мы использовали механизм CGo, однако первые тесты показали, что производительность CPU практически не улучшилась из-за его медлительности. В итоге мы переписали CGo, создав собственный механизм вызова.
В статье разберём, что такое CGo и почему он такой медленный, сделаем простейший собственный механизм CGo-вызова и доведём этот механизм до полноценного решения.
UTF-8 валидация — одна из базовых операций при работе с текстом, которая выполняется миллионы раз в секунду в современных приложениях. Стандартная реализация в Go, хоть и корректная, далека от оптимальной по производительности. В этой статье расскажу, как мне удалось ускорить валидацию UTF-8 в 10 раз, используя SIMD‑инструкции ARM NEON и алгоритм из статьи «Validating UTF-8 In Less Than One Instruction Per Byte» Джона Кейзера и Дэниела Лемира.
Как вычислить экспоненциальную функцию быстро и с минимальной погрешностью? Пишем векторизованный код.
Представлен цифровой фильтр без использования явной аппаратной или программной операции умножения, выполненный на основе двоичных сдвигов. Имеет дискретный ряд АЧХ, ФЧХ, при этом, эффективно реализуется на простейших контроллерах.
Почему при сложениии одинаковых чисел в разном порядке получаются разные результаты?
Как мининмизировать ошибки округления или избавиться от них совсем?
