x86 инструкции действительно заслуживают название Complex Instruction Set Computer (CISC) из-за своей чрезвычайно сложной структуры. Инструкции могут достигать 15 байт в длину, включая префиксные байты, которые изменяют поведение существующих команд, а не расширяют opcode. Процессор поддерживает два основных типа opcode: стандартный 1-байтовый и расширенный 2-байтовый с префиксом 0Fh, что теоретически позволяет до 512 различных классов инструкций. Бит направления (d) в opcode определяет направление передачи данных, а бит размера (s) указывает на 8-битные (s=0) или 16/32-битные (s=1) операнды.

Ключевым элементом является MOD-REG-R/M байт, который определяет операнды и режимы адресации. Поле MOD указывает на режим адресации (00-11), REG определяет регистр (от AL до EDI в зависимости от размера данных), а R/M совместно с MOD указывает второй операнд или единственный операнд для команд вроде NOT. Общие регистры (EAX, EBX, ECX и др.) обеспечивают быстрый доступ к данным, так как процессор работает с ними значительно быстрее, чем с памятью. 32-битные регистры содержат в себе свои 16-битные и 8-битные аналоги, что позволяет гибко работать с данными разных размеров.

• Обсуждение началось с размышлений о сложности кодирования инструкций в x86 и ARM64, где последний оказался значительно проще в этом плане.
• Участники обменялись ссылками и инструментами, включая вики-страницу "x86 is an octal machine" и репозиторий Paul Hsieh's.
• Была затронута тема эволюции процессора: сравнение 8086 и современных чипов, а также затрагивающая влияние на эффективность кода.
• Обсуждались трудности с кодированием инструкций в x86, включая непредсказуемость длины кода и сложность дешифрации.
• В итоге, участники сошлись на том, что эволюция процессора и архитектуры влияет на эффективность кода, и что важно адаптироваться к изменениям.

Проект MyraOS представляет собой операционную систему Unix-подобного типа для архитектуры x86, созданную с нуля без использования стороннего кода. Автор проекта Dvir Biton разработал ядро системы, файловую систему, драйверы и пользовательские утилиты самостоятельно, что делает его впечатляющим достижением в области разработки ОС.

Система поддерживает базовые функции Unix, включая многозадачность, управление памятью и взаимодействие с пользователем через командную строку. Проект открыт на GitHub и может быть использован для образовательных целей или как основа для дальнейших разработок. Код написан на ассемблере и C, что обеспечивает эффективную работу на аппаратном уровне.

• Проект получил много похвал за качество кода и полезность, но также вызвал критику за использование устаревших ресурсов и отсутствие современных инструментов.
• Участники обсуждали, что в 2025 году нужно обновить учебные материалы для новичков в разработке ОС, чтобы они не ориентировались на 32-битный x86 и устаревшие устройства.
• Предложения включали: предоставление ISO-образов для тестирования, создание обучающего видео, и сотрудничество с такими проектами как copy.sh.
• Также обсуждались проблемы, такие как управление памятью и отладка, и как они масштабируются в контексте разработки ОС.
• В конце обсуждение сошлось на то, что проект является вдохновляющим примером, но может быть улучшен с использованием современных практик и инструментов.

Создание эмулятора RISC-V на Rust — это активно развивающийся проект, позволяющий собрать 64-битный эмулятор с нуля. После завершения курса вы сможете запускать в нем xv6 — простую Unix-подобную операционную систему. Проект охватывает основы компьютерной архитектуры: ISA, привилегированный режим, исключения, прерывания, периферийные устройства и системы виртуальной памяти. Исходный код доступен на GitHub в репозитории d0iasm/rvemu-for-book.

Проект разделен на два основных раздела: в первом рассматриваются аппаратные компоненты, необходимые для работы xv6, включая процессор с двумя инструкциями, память, системную шину, регистры управления и состояния, а также контроллеры прерываний и UART. Второй раздел посвящен наборам инструкций, начиная с базового RV64I Integer и включая расширения "M" для умножения и деления, и "A" для атомарных операций.

• Доступны только первые три главы из десяти.
• Рекомендация использовать ассемблер для реализации.
• Наличие rv64-интерпретатора на x86_64 ассемблере.

• @mrasong отметил, что несмотря на отсутствие опыта работы с ассемблером, получил много полезной информации из статьи.
• @jmspring поделился опытом работы с ассемблером в прошлом (включая inline-оптимизации для криптоопераций), но сейчас предпочитает использовать ИИ для решения задач.
• @indyjo привел примеры необычных современных применений ассемблера: программирование для Atari ST в 2025 году и обучение роботов игре в DOOM.

x86-64 Playground — это веб-приложение для экспериментов с ассемблером x86-64, сочетающее онлайн-редактор кода и отладчик в стиле GDB. Пользователи могут писать, компилировать и делаться кодом для популярных ассемблеров, включая GNU As, Fasm и Nasm. Уникальность платформы — возможность пошагового выполнения программ с инспектированием памяти и регистров, а также поддержка перетаскивания и отладки любых статических исполняемых файлов Linux без установки дополнительного ПО.

Приложение ориентировано на академическую среду и изучение бинарной эксплойтации, с интерфейсом, напоминающим GDB+PwnGDB. Разработчики уделили особое внимание мобильному опыту, сделав интерфейс адаптивным и позволяющим встраивать редактор и отладчик на другие сайты. Проект с открытым исходным кодом работает полностью на стороне клиента через Blink Emulator, что обеспечивает конфиденциальность и возможность работы офлайн после загрузки.

• Инструмент позволяет запускать x86-64 машинный код в браузере без бэкенда, используя модифицированный эмулятор blink.
• Проект ориентирован на обучение: интерфейс напоминает GDB, но не реализует продвинутые функции отладчика.
• Пользователи отметили проблемы с инструкцией lzcnt, отсутствие гайдов и неработающие ссылки «Share» и «Guides».
• Появились вопросы о поддержке других архитектур, включая 6502, Game Boy и ARM, а также о возможности GPU PTX.
• Сообщество отметило, что проект полезен как интерактивный учебный ресурс, но не заменяет полноценный отладчик.

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

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

• Создание ОС с нуля на базе устаревшего BIOS и x86 рассматривается как учебный, но непрактичный путь, погружающий в исторические детали архитектуры вместо современных концепций.
• Многие проекты ОС остаются незавершенными из-за сложности поддержки железа и драйверов, что является рутинной и нетривиальной задачей.
• В качестве более актуальных альтернатив предлагаются подходы с использованием микрокернелов, современных архитектур (RISC-V, ARM) или существующих педагогических ОС (xv6).
• Рекомендуется начинать с изучения авторитетных источников (например, wiki.osdev.org) и современных туториалов, избегая устаревших материалов с пробелами и ошибками.
• Разработка ОС углубляет понимание распределенных систем, планирования и кэширования, что полезно для инженеров, даже если они не планируют писать ядро.

Safepoints — это ключевой механизм синхронизации в Fil-C и других виртуальных машинах, обеспечивающий безопасность памяти в многопоточной среде. Они позволяют потокам делать предположения о состоянии VM и сообщать о своём текущем состоянии, что критично для точного сборщика мусора, отладки и профилирования. Без safepoints не было бы возможности безопасно сканировать стеки, обрабатывать сигналы или использовать fork.

Fil-C вставляет pollchecks — проверки на необходимость остановки — на каждом обратном ребре управления в коде. Это короткая инструкция вроде testb, которая при срабатывании переходит к медленному пути обработки. Такой подход гарантирует, что GC может прервать поток только в безопасных точках, избегая проблем с регистрами или векторными инструкциями, и сохраняя корректность без invasive изменений в компиляторе.

• Fil-C использует механизм pollchecks для остановки потоков (stop-the-world), что необходимо для корректной работы fork(2), но поддержка vfork(2) пока отсутствует и требует нестандартных решений.
• Внедрение safepoint-ов в ассемблерный код рискованно и может нарушить предположения Fil-C о безопасности памяти; в долгосрочной перспективе планируется создать способ написания безопасного ассемблерного кода.
• Подход Fil-C к сборке мусора с опросом точек остановки (polling) создает нагрузку в tight loops, что решается разными оптимизациями (например, разверткой циклов), в отличие от асинхронных сигналов в Go.
• Мнения о читаемости и понятности реализации Fil-C разделились: одни участники находят ее интересной и хорошо объясненной, другие признаются, что не до конца понимают детали.
• Утверждение, что Java использует исключительно compacting GC, является упрощением, учитывая множество доступных конфигураций сборщика мусора в разных реализациях JVM.

Изучение x86-64 ассемблера через создание GUI с нуля

Филипп Гольтье

• Работы
• Теги
• Резюме

⏴ Назад ко всем статьям

Опубликовано 31.05.2023

Большинство считает ассемблер языком для учебных программ или оптимизации отдельных функций. Но что если написать на нём полноценную GUI-программу? Это будет «Hello World» для графического интерфейса, но всё же. Результат:

Меня вдохновила мысль: современные бинарные файлы часто весят 30+ МБ — а насколько маленьким может быть GUI? Оказалось, всего около 1 КБ!

Я не эксперт в ассемблере или X11, но надеюсь дать понятное руководство для начинающих. Ошибки? Сообщайте в Github.

Примечание: Аутентификация в X11 опциональна, но некоторые серверы (например XWayland) требуют её. Здесь она опущена.

Что потребуется?

Используем ассемблер nasm — простой, кроссплатформенный и быстрый. Для GUI возьмём X11, так как он работает без внешних библиотек. На Wayland должно работать через XWayland, на macOS — с XQuartz (но потребуется формат macho64 и иные значения системных вызовов).

Разница между ОС сводится к значениям системных вызовов. Для Linux укажем свои, для FreeBSD — другие, используя макросы nasm:

%ifdef linux
  %define SYSCALL_EXIT 60
%elifdef freebsd
  %define SYSCALL_EXIT 1
%endif

Компилируем на Linux, отправляем другу на FreeBSD — и оно работает!

Linux — единственная ОС со стабильным ABI. Другие могут его ломать, но для базовых вызовов это редкость.

Основы X11

X11 — это сервер, управляющий окнами и отрисовкой. Клиент подключается через сокет, отправляет команды на открытие окон, рисование и т.д., а сервер присылает события и ошибки.

Обычно используют libX11 или libxcb, но мы сделаем всё сами. Сервер может быть хоть на другом конце света — это не важно для клиента.

• Обсуждение началось с проекта по изучению ассемблера x86-64 через написание GUI "с нуля", но многие отметили, что использование X-сервера не является истинным "с нуля".
• Несколько пользователей поделились личным опытом изучения ассемблера через различные проекты: написание приложения на GTK, работу с микроконтроллерами PIC и создание собственного виртуального процессора.
• Было высказано мнение, что работа с "сырым" X-протоколом не сложна, но утомительна из-за его асинхронной природы и необходимости сериализации/десериализации запросов.
• Участники дискутировали о том, что на самом деле означает термин "с нуля" (from scratch), от сравнительно простого использования API до создания всей системы самостоятельно.
• В качестве сравнения был приведен пример с Win32, где создание GUI заключается в основном в заполнении структур и вызове функций.
• Было отмечено, что проект, несмотря на спорное определение "с нуля", является более сложным и продвинутым, чем многие аналогичные попытки.
• Один из комментаторов указал на проблему с поддержкой высокого разрешения в XQuartz для пользователей macOS.

microsoft/BASIC-M6502 — официальный репозиторий Microsoft BASIC для процессора 6502, версия 1.1.
Расположен исходный код на ассемблере 6502, включая оригинальные комментарии 1978 г. и лицензионные файлы.

• Microsoft выложил исходники MS-BASIC для 6502 с «коммитом 48 лет назад» и пасхалкой WAIT 6502,X, которая выводит «MICROSOFT!».
• Код — один 162-КБ файл без модулей; удивляют старые редакторы и скорость сборки на PDP-10.
• В комментариях всплывают Applesoft BASIC, Commodore, Ohio Scientific и другие наследники этой версии.
• Пользователи делятся ностальгией, просят открыть Z80- и VB6-порты, обсуждают лицензию и «AI-аромат» README.

Коллега нашёл в ARM-дизассемблере кучу «лишних» инструкций d4d4 (bmi #-0x58), которые никогда не выполняются.

Минимальный пример:

00020100 <one>:
   20100: 4770  bx lr
   20102: d4d4  bmi …

bx lr возвращает из функции, так что d4d4 недостижима.
Мысль: выравнивание? Thumb-команды 16-битные, но компилятор не выравнивает функции на 32 бита.

Добавляем вторую функцию — d4d4 исчезает.
Третья — d4d4 снова появляется, но только после последней функции.

Смотрим объектный файл: компилятор d4d4 не вставляет. Значит, линковщик lld добивает секцию до 32-битной границы именно этой командой.
Меняем порядок файлов — «лишняя» инструкция перемещается в начало следующего модуля, подтверждая гипотезу.

GNU ld вместо d4d4 ставит нули.

• Коммит 2017 года в OpenBSD закладывал «trapsleds» — заполнение «дырок» в исполняемых секциях инструкциями-ловушками (trap), чтобы сорвать NOP-sled-эксплойты.
• На ARM32/Thumb ожидалось 0xD4 (BRK) или 0xBE (BKPT), но в режиме Thumb та же последовательность байтов декодируется как условный переход назад, превращая «ловушку» в потенциальный ROP-гаджет.
• Это делает защиту нерабочей на Cortex-M (только Thumb), что участники признают ошибкой/«сломанной» митигацией.
• Некоторые считают, что описание механизма в коммит-сообщении достаточно, другие требуют комментариев в коде, чтобы избежать подобных недоразумений.

Репозиторий FFmpeg

• 120 755 коммитов, 38 веток, 408 тегов, размер 271 МиБ
• Языки: C 90 %, Assembly 8 %, Makefile 1 %, остальное <1 %

Ветка master

• Последний коммит: a2cfaf1 — avformat/mov: передавать индекс потока в sanity_checks для HEIF
• CI: все проверки успешны (linux-amd64, linux-aarch64, Windows, lint)

Ссылки

• ZIP | TAR.GZ | BUNDLE

Последние изменения

• libavformat: передача индекса потока в sanity_checks для HEIF (James Almer)
• libavcodec: очистка pu_info в rv60dec
• fftools/ffmpeg_mux_init: 64-битные вычисления score
• libswscale: выравнивание на 8 строк для planarCopyWrapper
• doc/examples: замена sleep на av_usleep
• presets: удалены устаревшие пресеты iPod

• FFmpeg ушёл с GitHub на самостоятельный Forgejo, отказавшись от рассылок и ускорив навигацию по файлам.
• Пользователи жалуются на защиту Anubis с «аниме-девочкой»: ошибки «Invalid Response», пропадающий CSS, проблемы на Android.
• Критика мотива «не Microsoft» и вопросы: почему именно Forgejo, а не GitLab/Gitea.
• Сторонники отмечают суверенитет и удобство, противники — нестабильность и «нелепый» брендинг.

XR2000 — новый программистский квест в жанре научной фантастики.
Он объединяет бинарные протоколы, криптографию и развёрнутый сюжет, который пока охватывает лишь первую главу. Дальнейшее зависит от интереса участников.

Вдохновение дали:

• TIS-100 — псевдоассемблер в игровой форме.
• Space Traders — космическая торговля через REST API.
• Protohackers — челленджи по сетевым протоколам.

Старт:

nc clearsky.dev 29438

Приятного погружения!

• Участники делятся ссылкой на похожий Sci-Fi-контест 2006 года, где нужно писать собственную VM.
• Появился новый TCP-пазл на clearsky.dev:29438; при подключении требуется отправить 0-байт + «XR2K» для документации.
• Сервер перегружен HN, поэтому текст иногда не выводится или после команды ничего не происходит.
• Некоторые пробуют использовать LLM для упрощения игры.
• Один из игроков ждёт ответа «Colonel Arhci» по atlantiamail.

Как обогнать memcpy

Профилируя Shadesmar, увидел: при больших (>512 КБ) сообщениях 97 % времени уходит на memcpy между процессной и разделяемой памятью. Решил ускорить копирование.

---

Разбор memcpy

perf показал:
__memmove_avx_unaligned_erms — это memcpy через memmove, AVX, 32 байта за раз, поддержка не выровненных блоков и ERMS (железный цикл REP MOVSB).

• memmove выбран, т.к. допускает перекрытие.
• Для <4 КБ используется SSE2, иначе — REP MOVSB + AVX.
• Не-временные (NT) инструкции и prefetcht0 уменьшают кэш-промахи.

---

Способ 1: простой REP MOVSB

void _rep_movsb(void *d, const void *s, size_t n) {
  asm volatile("rep movsb"
               : "=D"(d), "=S"(s), "=c"(n)
               : "0"(d), "1"(s), "2"(n)
               : "memory");
}

Тот же цикл, что и в glibc, но без лишней логики.

• Часть выгоды даёт отказ от лишнего копирования: часто данные можно использовать на месте.
• Несколько участников отмечают, что без контроля кэшей и правильной сериализации бенчмарки теряют смысл.
• График в конце вызывает сомнения: скачки пропускной способности выглядят неправдоподобно.
• Для IPC обсуждают zero-copy через размещение данных сразу в shared memory (Iceoryx, Boost.Interprocess, DPDK).
• Большинство сходится к выводу: для обычных задач лучше довериться стандартному memcpy/std::memcpy, особенно в glibc.