Ironclad — это формально верифицируемый, реального времени, UNIX-подобный ядро операционной системы общего назначения и встраиваемых систем, написанное на SPARK и Ada. Проект полностью свободный и распространяется под лицензией GPLv3. Ключевые особенности включают POSIX-совместимый интерфейс, одновременное вытесняющее многозадачность, обязательный контроль доступа (MAC) и поддержку жёсткого реального времени.

Главное преимущество Ironclad — формальная верификация с помощью SPARK для критических компонентов, таких как криптография и MAC. Система полностью портативна и зависит только от GNU toolchain, что упрощает кросс-компиляцию. Проект поддерживает дистрибутивы для всех доступных архитектур, наиболее заметный из которых — Gloire. Ironclad всегда будет бесплатным для использования, изучения и модификации, а финансируется за счёт пожертвований и грантов от NLnet и Европейской комиссии.

• Участники сомневаются в степени формальной верификации Ironclad, сравнивая его с более строгими аналогами вроде seL4 и Tock, и указывают на отсутствие доказательства ключевых свойств ядра.
• Проект написан на SPARK и Ada, поддерживает x86_64 и RISC-V, но не ARM64; его лицензия включает бесплатную версию с возможностью коммерческого использования.
• Основные альтернативы: seL4 (быстрый и строго верифицируемый), Genode (POSIX-совместимый слой), Asterinas и Redox (Linux-совместимые ядра), а также ReactOS и SerenityOS.
• Критика включает медленную производительность по сравнению с seL4, отсутствие capability-based безопасности и потенциальные проблемы на уровне прошивки.
• Уточнено, что формальная верификация — это не тестирование, а математическое доказательство соответствия спецификации, а "бесплатность" ПО может относиться только к лицензии.

Ubuntu 25.10 представляет поддержку архитектурных вариантов, в частности amd64v3 (x86-64-v3), позволяя оптимизировать пакеты под современные процессоры без потери совместимости со старым оборудованием. Для этого были изменены dpkg, apt и Launchpad, чтобы создавать несколько версий пакетов для разных уровней архитектуры. В текущем релизе около 2000 пакетов в компоненте "main" уже пересобраны, но они не прошли полное тестирование, поэтому возможны ошибки. Бенчмарки показывают прирост производительности около 1% для большинства пакетов и больше для числовых приложений.

Большинство облачных экземпляров и машин за последние 10 лет поддерживают x86-64-v3, что можно проверить командой ld.so --help | grep '\-v[0-9]'. Чтобы включить amd64v3, нужно установить последнюю версию dpkg и добавить конфигурацию APT::Architecture-Variants "amd64v3"; в /etc/apt/apt.conf.d/99enable-amd64v3, затем обновить систему. Важно, что после установки amd64v3 версий пакетов перенос жесткого диска на старое оборудование без поддержки x86-64-v3 станет невозможен. В 26.04 LTS эта проблема будет решена, а все пакеты будут пересобраны и полноценно протестированы.

• Ubuntu 25.10 предлагает оптимизированные пакеты для x86-64-v3 (AVX2), но не делает акцент на этом в анонсе.
• Сторонние репозитории уже предоставляют оптимизированные пакеты для разных уровней ISA, что делает спор о «1 % прироста» не столь значимым.
• Вопрос о том, стоит ли жертвовать совместимостью ради 1 %, остаётся открытым, особенно если учесть, что в будущем может появиться v4 или v5.
• Пользователи обеспокоены, что не смогут вынуть диск и загрузиться на старом ноутбуке в случае сбоя.
• Сторонние репозитории уже предоставляют оптимизированные пакеты для разных уровней ISA, что делает спор о «1 % прироста» не столь значимым.

Предоставленный текст не содержит содержимого статьи о средстве перевода Rosetta от Apple Developer Documentation. Вместо этого там лишь сообщение о необходимости включить JavaScript для просмотра страницы. Без доступа к фактическому содержанию статьи невозможно создать её точный и ёмкий пересказ в соответствии с требованиями.

• Apple объявляет о прекращении поддержки Rosetta 2 через два года, что фактически означает конец эпохи x86-64 на macOS.
• Разработчики и пользователи обсуждают, что это означает для сторонних приложений, которые не будут пересобраны под ARM, и как это повлияет на Docker, игры и другие инструменты.
• Обсуждается, что Apple могла бы открыть исходники Rosetta 2, чтобы сообщество могло бы продолжать поддержку.
• Участники обсуждают, что это может повлиять на Hackintosh и на то, что macOS может больше не поддерживать x86-64.
• Участники также обсуждают, что это может повлиять на игры, которые не будут пересобраны под ARM.

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.
• Сообщество отметило, что проект полезен как интерактивный учебный ресурс, но не заменяет полноценный отладчик.

• Появление аппаратной поддержки тегирования памяти в x86-64 — это ответ на уже существующие технологии ARM64 (MTE) и Apple (MIE), а не новая идея.
• Технически это не более чем перенос существующих подходов на x86-64, но важно, что это может быть сделано опционально и не сломает существующий код.
• Поддержка тегирования памяти в x86-64 может быть реализована в виде набора инструкций, которые будут использоваться компилятором и стандартной библиотекой, чтобы обеспечить безопасность кода, написанного на C/C++.
• Это не решит проблему безопасности памяти в целом, но может помочь в обнаружении ошибок и предотвращении эксплойтов.

Изучение 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.

TPDE-LLVM — новый бэкенд LLVM-O0, который в 10–20 раз быстрее стандартного, при сопоставимой скорости выполнения и росте кода на 10–30 %. Работает с IR Clang-O0/O1, цели x86-64 и AArch64.
Данные SPEC CPU 2017 (x86-64, ускорение компиляции и размер кода относительно LLVM 19 -O0):

бенчмарк	O0 IR	O1 IR
perl	11.4× / 1.27×	15.1× / 0.97×
gcc	12.5× / 1.32×	17.6× / 1.01×
omnetpp	21.5× / 1.24×	26.5× / 1.03×
геом.ср.	13.3× / 1.27×	17.6× / 0.97×

Как работает: три прохода — очистка IR, анализ (циклы + liveness), единый codegen (lowering, регистры, кодирование).
Поддержка: как библиотека, llc-подобный инструмент, патч для Clang. DWARF и улучшенный рег-аллокатор в планах.
Ограничения: не все IR-конструкции, векторы, TLS-глобалы, i260 и т.д.

Что ускорило бы LLVM ещё сильнее:

• убрать ConstantExpr внутри функций;
• запретить гигантские структуры/массивы как значения;
• упростить доступ к TLS и произвольную битовую арифметику.

• Пользователи обсудили, что Gentoo всё ещё используют с флагом -O8 для максимальной производительности.
• Кто-то спросил, нужно ли добавить пометку «(2020)» к цитируемому тексту.
• Упомянули, что «все» якобы перешли на Arch, где компилятор якобы умеет -O11.
• Уточнили: пост 2025 года, но он цитирует запись 2020-го; попросили модератора исправить.

TPDE-LLVM: 10-20× быстрее -O0
Новый open-source бэкенд TPDE-LLVM ускоряет компиляцию в режиме -O0 в 10–20 раз при сопоставимой скорости выполнения и увеличении кода на 10–30 %. Поддерживаются x86-64 и AArch64, типичное IR Clang O0/O1.

SPEC 2017 (x86-64)	Ускорение	Размер
perl	11.4×	1.27×
gcc	12.5×	1.32×
mcf	9.7×	1.27×
omnetpp	21.5×	1.24×
xalanc	19.0×	1.24×
x264	10.5×	1.26×
deepsjeng	9.6×	1.25×
leela	21.4×	1.24×
xz	11.0×	1.30×
geomean	13.3×	1.27×

Как работает
Три прохода: очистка IR, анализ (циклы + живость), кодогенерация (lowering, регистры, код) за один проход. Подробности — в статье.

Планы

• DWARF, улучшенный регистровый аллокатор.
• Поддержка Flang/Rust неполная (векторы, FP-операции).
• Нет non-ELF, других целей.

Использование
Библиотека, llc-подобный инструмент, патч для Clang.

Почему не ускорить LLVM?
LLVM 18→20 стал быстрее на 18 %, но 10× требует радикальных изменений.

Что мешает ещё быстрее

• ConstantExpr внутри функций.
• Структуры/массивы произвольного размера.
• Прямой доступ к TLS-глобалам.
• Арифметика произвольной битности (i260).

Факты

• 4 байта padding в Instruction для служебных номеров.
• PHINode::getIncomingValForBlock квадратичен при >1 k предков.
• 90 % времени tpde-llc — парсинг биткода.

• TPDE — новый бэкенд, генерирующий код на 10–20× быстрее LLVM, но чуть медленнее -O0.
• Участники спорят, насколько «парето-улучшение» реально: поддерживается лишь «типичное» подмножество LLVM-IR, векторные инструкции и экзотика не работают.
• Некоторые вспомнили Copy-and-Patch и другие подходы, где LLVM используется для библиотеки патчей, но теряется 2,5× в рантайме из-за регистров.
• Основная узкость теперь — фронтенды (rustc, Clang), которые даже при TPDE занимают >98 % времени сборки.
• Желают скорейшего переноса в Swift и Wasmer, но сомневаются в готовности сообщества LLVM что-то менять.

FFmpeg/asm-lessons — репозиторий с уроками по ассемблеру для FFmpeg.
Цель: научиться писать высокопроизводительные рутины на x86-64, ARM и других архитектурах, ориентированные на мультимедиа-задачи.

Содержание (кратко):

• Уроки: от базовых инструкций до векторных расширений (SSE/AVX, NEON).
• Примеры: реализация IDCT, фильтров, цветового преобразования.
• Тесты: юнит-тесты и бенчмарки для сравнения C vs asm.
• CI: автоматическая проверка на x86-64 и ARM через GitHub Actions.

Как начать:

1. Клонируйте репо.
2. Установите nasm, yasm или llvm-mingw.
3. Соберите пример: make lesson01.

Полезные ссылки:

• Документация FFmpeg
• x86 SIMD
• ARM NEON

• Пользователи восхищаются масштабом FFmpeg и экономией вычислений даже при небольших улучшениях.
• Обсуждаются случаи, когда ручная сборка быстрее intrinsic’ов, и инструменты для поиска «горячих точек».
• Некоторые ждали более глубокой связи с FFmpeg, а не общее введение в ассемблер.
• Поднимаются вопросы портативности (пока только x86-64), необходимости математических подготовок и перегруженности NASM-макросами.
• Большинство соглашается: писать LLVM IR вручную нет смысла, проще использовать inline-assembly или векторные инструкции.