Fil-C получила первую в мире реализацию безопасной по памяти встраиваемой ассемблерной вставки (inline assembly) для архитектуры x86_64. Эта фича пока предрелизная — в версии 0.679 её нет, нужно собирать из исходников.
Проблема в том, что обычная inline assembly в C/C++ — это, по сути, дыра в безопасности. Программист может случайно пропустить + в "+r" или забыть указать "cc" в clobber-списке, и компилятор просто выдаст неработающий код. Fil-C же умеет проверять такие вставки и, если что-то пошло не так, вместо молчаливого сбоя вызывает панику или ловит illegal instruction trap.
Зачем вообще нужна inline assembly? Автор перечисляет основные сценарии. Первый — пустые вставки вроде asm volatile("" : : : "memory"), которые работают как барьер для оптимизаций компилятора (важно для constant-time криптографии). Fil-C такие вставки поддерживал давно. Второй — инструкции cpuid и xgetbv для определения возможностей CPU: их часто используют библиотеки вроде zstd и simdutf, потому что стандартный __get_cpuid работает ненадёжно. Третий — арифметика над секретными данными в криптокоде (например, OpenSSH's sntrup761), где нужно гарантировать одинаковое время выполнения. Четвёртый — атомики (пока не поддерживаются для работы с памятью, но fence-инструкции типа mfence уже есть). Пятый — работа с 80-битными long double на x87.
Ключевая инновация — способ валидации. Разработчик Fil-C не стал вручную писать парсер x86_64 ассемблера, а просто сформулировал задачу в промпте для ИИ-агента T800, работающего на модели Kimi K2.7-code. Агент написал функцию validateSafeInlineAsm, которая анализирует строку ассемблера и ограничения (constraints) на уровне LLVM IR. Если инструкция не из белого списка, содержит обращения к памяти или управление потоком, или если её эффекты (например, изменение регистров) не описаны в constraints — вставка отклоняется.
Белый список пополнялся в автоматическом режиме: T800 запускал цикл с суб-агентами, которые по очереди добавляли новые безопасные pre-AVX512 инструкции, пока список не покрыл сотни мнемоник — от простых sar и xor до x87 и SIMD. Интересно, что для первой половины работы использовалась Kimi K2.7-code (более осторожная), а для второй — GLM 5.2 (быстрее и смелее).
Важный нюанс: ошибка в inline assembly не ловится на этапе компиляции. Fil-C просто заменяет небезопасную вставку на панику с диагностикой, а если инструкция не поддерживается CPU — вызывается illegal instruction trap (перехватить SIGILL в Fil-C нельзя). Это удобно для портирования: dead code с ассемблером не мешает, а ошибки проявляются только при реальном выполнении.