Эволюция ассемблера в язык системного программирования нового поколения.

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

С другой стороны — современные тяжеловесы вроде C++ и Rust. Они предлагают мощнейшие абстракции, безопасность типов и выразительность, но требуют сделки с дьяволом: колоссального усложнения компилятора, непредсказуемого декорирования (mangling) имён, скрытых аллокаций и гигантских runtime-прослоек. Вы больше не контролируете железо; вы просите компилятор сделать это за вас, надеясь, что эвристика оптимизатора (LLVM или GCC) совпадет с вашими ожиданиями.

С выходом версии v32.0.0-rev1.0, компилятор AsmX совершает эволюционный скачок. Внедрение нового ядра Raptor Engine превращает AsmX в полноценный язык системного программирования. Эта статья — подробное руководство по архитектуре нового релиза. Мы разберём, как AsmX реализует объектно-ориентированные концепции, шаблоны, безопасный паттерн-матчинг и строгую ABI-совместимость, не жертвуя при этом своей изначальной философией: давать разработчику абсолютный контроль над железом, упакованный в математически доказанную безопасность.

Глава 1. Философия и точка входа без CRT (Zero-Overhead Entry)

Если вы напишете простейшую программу «Hello World» на C или C++, скомпилируете её и дизассемблируете, вы с удивлением обнаружите, что функция main не является истинной точкой входа в программу.

Ядро операционной системы Linux при запуске процесса (через системный вызов execve) передаёт управление функции _start, которая любезно предоставляется стандартной библиотекой C (CRT — C Runtime, например, glibc). Эта скрытая функция выполняет огромную работу: инициализирует среду, настраивает векторы прерываний, подготавливает Thread-Local Storage (TLS) и лишь затем, спустя тысячи тактов процессора, вызывает ваш main(argc, argv, envp).

Raptor Engine избавляется от этой прослойки. В AsmX концепция Zero-Overhead возведена в абсолют. Функция main является буквальной, физической точкой входа (Entry Point) в исполняемый файл.

Как же тогда программа получает аргументы командной строки без помощи libc? Ответ кроется в глубоком понимании архитектуры Linux. При передаче управления ядро формирует стек процесса в строгом формате:

По адресу [rsp] лежит 8-байтовое целое число argc (количество аргументов).
Начиная с [rsp + 8], располагается массив указателей argv (строки аргументов).
Далее следует обязательный маркер NULL.
Следом располагается массив указателей envp (переменные среды).

Raptor Engine знает об этом. Компилятор AsmX генерирует для функции main уникальный, высокооптимизированный пролог.

// Точка входа в AsmX. Никакого C Runtime.
fn main(int32_t args_count, char** args, char** env) {
  // Напечатаем все аргументы программы напрямую!
  int32_t i = 1;
  while (i < args_count) {
    const char* current_arg = args[i];
    int32_t len = strlen(current_arg);

    syscall_write(1, current_arg, len);
    syscall_write(1, "\n", 1);

    i = i + 1;
  }

  // Явный системный вызов завершения процесса
  @mov $60, %rax; // sys_exit
  @mov $0, %rdi;  // exit code 0
  @syscall;
}

На уровне аппаратных инструкций компилятор перехватывает сырые данные со стека ядра. Например, для безопасного получения указателя env (переменные среды) используется аппаратная адресация SIB (Scaled Index Byte). Процессор вычисляет адрес одной инструкцией lea rax, [rbp + rcx*8 + 24], где %rcx — это argc.

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

1.12. Прямой доступ к кремнию: SIB-адресация и расширенный набор инструкций CPU

Переход компилятора от текстовых подстановок к строгому анализу типизированных операндов позволил Raptor Engine открыть разработчикам полноценный доступ к сложным режимам адресации процессоров x86-64. Центральное место здесь занимает поддержка SIB (Scale-Index-Base) синтаксиса для работы с памятью.

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

@mov (%rax, %r15, 2), %rdx; // [base + index * scale]

Что происходит под капотом компилятора:

Подсистема operand-parser.cts при разборе аргументов инструкции перехватывает круглые скобки. Если внутри обнаруживается кортеж (список через запятую), парсер мгновенно переключает состояние и выделяет этот операнд как внутренний тип memory_sib.
Компилятор производит жесткую валидацию компонентов: базовый регистр (%rax) и индексный регистр (%r15) проверяются на физическое существование в архитектуре AMD64, а коэффициент масштабирования (Scale) строго сверяется с аппаратной маской процессора. Допускаются только множители 1, 2, 4 или 8. Любое другое число вызовет ошибку компиляции на этапе парсинга операндов.
Класс HardwareMachineFactoryParserOpernadType транслирует валидированный узел memory_sib напрямую в бинарный код, вычисляя значения байта ModR/M и опционального байта SIB. Программист получает "голый" доступ к адресации CPU без накладных расходов.

Расширение нативного набора инструкций (генератор tbl.cts)

Помимо усложнения операндов, ядро генератора Raptor Engine пополнилось критически важными инструкциями, которые позволяют избавиться от костылей при работе со знаковыми типами и стеком:

movsx (Move Sign-Extend) & movzx (Move Zero-Extend): Ранее приведение типов (например, расширение int8_t до int32_t) было кошмаром. Теперь TypeChecker при обнаружении явного или безопасного неявного расширения типов генерирует эти инструкции. movsx копирует значение, заполняя старшие биты целевого регистра знаком исходного числа (важно для знаковой арифметики), а movzx зануляет старшие биты (для беззнаковых типов).
pop: Идеальный компаньон для имеющейся инструкции push. Позволяет проводить деликатные ручные манипуляции со стеком CPU в обход стандартного пролога и эпилога функций, что незаменимо при написании переключателей контекста в шедулерах ОС.
mul & imul (Умножение):
mul выполняет беззнаковое умножение, а imul — знаковое. Компилятор учитывает, что классический mul неявно использует регистр %rax в качестве одного из сомножителей и верхнюю половину результата помещает в %rdx. Регистровый аллокатор компилятора теперь знает об этих неявных зависимостях и защищает данные в %rdx от перезаписи.
div & idiv (Деление):
Беззнаковое и знаковое деление соответственно. Как и в случае с умножением, эти инструкции жестко привязаны к паре регистров %rdx:%rax, где перед вызовом должно находиться делимое. Результат деления процессор отправляет в %rax, а остаток — в %rdx.
neg (Negate):
Выполняет операцию дополнения до двух (двоичное отрицание со сложением с единицей), физически меняя знак числа на противоположный на уровне регистра всего за 1 такт процессора.

Глава 2. Обзор ключевых возможностей: От синтаксиса к семантике

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

2.1. C-совместимые лексические основы

Первое, что бросится в глаза системному программисту — отказ от исторического ассемблерного синтаксиса комментариев. Двойная точка с запятой (;;) осталась в прошлом.

Для обеспечения бесшовной интеграции с современными IDE, системами подсветки синтаксиса (Syntax Highlighting) и инструментами статического анализа, AsmX перешел на стандарт C/C++:

Однострочные комментарии: //
Многострочные блоки: /* ... */

Это микроскопическое изменение имеет огромный психологический эффект: код на AsmX визуально воспринимается как безопасный высокоуровневый язык, скрывающий под собой ассемблерную мощь.

2.2. Рекурсивное расширение модулей (AST Splicing)

В языке Си система подключения внешних файлов #include <stdio.h> работает на уровне примитивного текстового препроцессора. Компилятор буквально копирует тысячи строк текста в ваш файл. Это приводит к экспоненциальному росту времени компиляции и заставляет разработчиков использовать #pragma once или include guards (#ifndef HEADER_H ...), чтобы избежать циклического копирования.

В Raptor Engine введены директивы @include (для стандартной библиотеки) и @import (для локальных модулей), работающие по принципу AST Splicing (Встраивание абстрактного синтаксического дерева).

// Импортирует стандартную библиотеку AsmX (stdlib)
@include "optional.asmx"; 

// Импортирует локальный модуль из текущей директории
@import "network_utils.asmx";

Когда компилятор видит эту директиву, он не вставляет текст. Он запускает изолированный парсер, читает целевой файл, строит для него Абстрактное Синтаксическое Дерево (AST), а затем напрямую «вшивает» узлы этого дерева в текущую программу.

Более того, компилятор аппаратно отслеживает абсолютные пути загруженных модулей. Если A.asmx импортирует B.asmx, а B.asmx импортирует A.asmx, компилятор математически отсекает циклическую зависимость, гарантируя нулевое дублирование кода и молниеносную скорость сборки.

2.3. Пространства имён и абсолютная изоляция

В чистом C разработчики вынуждены использовать префиксы для предотвращения конфликтов имён: openssl_md5_hash(), glfw_create_window(). C++ решает это через namespace, но добавляет головную боль в виде Argument-Dependent Lookup (ADL), когда компилятор неявно ищет функции в пространствах имён аргументов, ломая предсказуемость компоновщика (linkage).

AsmX реализует пространства имён со строгой детерминированной изоляцией и глубоким манглингом.

namespace std {
  fn execute() {
    // Внутренняя реализация
  }
}

namespace {
  // Анонимное пространство имен (доступно только в этом файле)
  fn hidden_task() { }
}

fn main() {
  std::execute(); // Явный вызов
  this::hidden_task(); // Доступ к анонимному пространству через this::
}

Анонимные пространства имён (вызываемые через квалификатор this::) гарантируют, что символ не будет экспортирован в глобальную таблицу символов бинарного файла (аналог static функций в C, но с гибкостью целого пространства имён).

2.4. Объектно-Ориентированный Ассемблер: Структуры и Инкапсуляция

Структуры в C — это просто способ сгруппировать данные в памяти. В AsmX структура (struct) — это полноправный субъект Объектно-Ориентированного Программирования.

Вы можете объявлять данные, методы, конструкторы и деструкторы в едином блоке. Важнейшим нововведением является строгая инкапсуляция на этапе компиляции с использованием ключевых слов pub (public), priv (private) и protected.

struct Point {
pub:
  int32_t x;
  int32_t y;
priv:
  int32_t hardware_id;
}

pub fn Point::get_id() -> int32_t {
  // Доступ к priv-полю разрешен, так как метод принадлежит структуре
  return this->hardware_id;
}

Если вы попытаетесь обратиться к point.hardware_id из функции main, компилятор выдаст фатальную ошибку: hardware_id is private in Point. В отличие от C, где для сокрытия данных (Opaque Pointers) нужно выделять память в куче (malloc), AsmX обеспечивает инкапсуляцию статически. Приватные данные могут безопасно лежать на стеке с нулевым оверхедом!

2.5. Магия неявного this

Обратите внимание на код выше. Мы обращаемся к this->hardware_id. Откуда взялся this?

В языке C для реализации методов вы обязаны вручную передавать указатель на структуру: Point_get_id(Point* self).

Raptor Engine автоматизирует этот процесс. Если компилятор видит, что функция объявлена с квалификатором структуры (Point::get_id), он на лету модифицирует AST, вшивая первым параметром указатель this типа Point*. На аппаратном уровне, следуя правилам System V ABI, этот указатель всегда будет передаваться в самом быстром регистре %rdi, что делает вызов методов AsmX столь же эффективным, как и вызовы в C++.

2.6. Конструкторы, деструкторы и анатомия инициализации

Чтобы обуздать хаос ручного управления памятью, AsmX вводит строгие концепции жизненного цикла объектов. Для этого используются квалификаторы constructor и destructor. В отличие от C++, где имена конструкторов жестко привязаны к имени класса, в AsmX вы используете оператор разрешения области видимости :: для явной привязки метода к структуре. Само имя метода может быть любым: init, create или даже просто _.

Более того, конструкторам необязательно возвращать указатель на себя (Self). Под капотом они работают как обычные функции, имеющие доступ к внедренному указателю this. Деструкторы также вызываются как обычные функции, но с одним железным правилом: перегрузка деструкторов запрещена, и они не могут принимать аргументы.

Посмотрим на классический пример жизненного цикла:

constructor Point::__init__(int32_t x, int32_t y) -> Point {
  this->x = x;
  this->y = y;
  this->hardware_id = 0xFF;
  return this;
}

Если вы попытаетесь передать аргумент в деструктор, семантический анализатор AsmX мгновенно оборвет компиляцию, защищая вас от неопределенного поведения:

pub destructor myStruct::deinit(int32_t a) {};

Ошибка компиляции:

[ExpressionException]: Destructor cannot have parameters
39 |	
40 |	pub destructor myStruct::deinit(int32_t a) {};
41 |	               ^------------------------------

Инкапсуляция и нюанс фигурных скобок {}

Как и поля данных, конструкторы подчиняются правилам доступа (pub, priv). Если вы попытаетесь напрямую вызвать приватный конструктор извне:

priv constructor myStruct::init() { ... };
// ...
ms.init();

Вы получите закономерную ошибку: [ExpressionException]: 'init' is private in 'myStruct'.

Однако в текущей версии Raptor Engine (v32.0.0-rev1.0) есть важная архитектурная особенность, о которой должен знать каждый разработчик. При использовании синтаксиса списочной инициализации {} компилятор автоматически связывает фигурные скобки с первым объявленным (дефолтным) конструктором, даже если он помечен как priv.

priv constructor myStruct::init() {
  syscall_write(1, "Init Priv\n", 10);
};

pub constructor myStruct::init_pub() {
  syscall_write(1, "Init Pub\n", 9);
};

fn main() {
  myStruct ms {}; // Вызовет приватный myStruct::init() !
  ms.init_pub();  // Легальный вызов публичного конструктора
}

Сейчас это поведение позволяет авторам библиотек создавать скрытые пути внутренней инициализации объектов (своеобразный бэкдор для системного кода), но в будущих RFC механику списочной инициализации планируется сделать более строгой.

2.7. Мономорфизация на лету: Шаблоны (Generics) без боли

Шаблоны в C++ невероятно мощные, но они печально известны тем, что замедляют компиляцию до скорости улитки и генерируют нечитаемые ошибки. Java и TypeScript идут другим путем — используют «стирание типов» (Type Erasure), превращая всё в безликие объекты в рантайме, что уничтожает производительность и требует боксинга (выделения памяти в куче).

AsmX использует мономорфизацию на уровне абстрактного синтаксического дерева (AST).

template<typename T>
struct vector {
  T* data;
  int32_t size;
};

// Использование
std::vector<int32_t> vec;

Когда парсер AsmX встречает определение template<typename T>, он вообще не генерирует машинный код. Он сохраняет AST-дерево в специальный реестр шаблонов. Когда компилятор доходит до строки std::vector<int32_t>, он приостанавливает работу, достает AST вектора, глубоко клонирует его, физически заменяет каждый токен T на int32_t и генерирует уникальное имя, например, vector__7int32_t.

Для процессора никаких шаблонов не существует. Он видит идеально оптимизированную, жестко типизированную структуру, созданную специально для int32_t. Вы получаете выразительность высоких абстракций с нулевой стоимостью в рантайме (Zero-Cost Abstractions).

2.8. Перегрузка функций и прозрачный манглинг

В чистом C функции не могут иметь одинаковые имена. Это заставляет разработчиков придумывать уродливые суффиксы: print_int(), print_float(), print_string().

В AsmX вы можете перегружать функции естественным образом:

fn use_overload(bool x) {
  syscall_write(1, "Bool variant\n", 13);
}

fn use_overload(int32_t x) {
  syscall_write(1, "Int32 variant\n", 14);
}

fn main() {
  use_overload(true); // Автоматически вызовет вариант для bool
}

Чтобы линкер (Linker) не сошел с ума, компилятор применяет механизм Name Mangling. Втихую от программиста функции переименовываются в use_overload__4bool и use_overload__7int32_t. Когда вы совершаете вызов, подсистема TypeChecker берет типы переданных аргументов и ищет идеальное совпадение. Если точного совпадения нет, компилятор пытается найти безопасное неявное приведение типов (например, расширить int16_t до int32_t).

2.9. Гарантированная оптимизация (RVO) и SRET-архитектура

Пожалуй, самым большим инженерным достижением релиза Raptor является полное, математически точное соблюдение конвенций System V AMD64 ABI при передаче структур.

Представьте, что функция возвращает std::optional<int32_t*>. Размер этой структуры — 16 байт (1 байт на boolean-флаг, 7 байт выравнивания, 8 байт на указатель). В 8-байтовый регистр %rax она не поместится.

Как AsmX решает эту проблему? Он разрезает структуру пополам! Младшие 8 байт возвращаются в регистре %rax, а старшие 8 байт — в регистре %rdx. Вызывающий код прозрачно собирает их обратно.

А что если структура весит 24 байта (как std::vector)? Здесь вступает в игру SRET (Struct Return - скрытый указатель).

std::optional<int32_t*> ptr_opt = std::make_optional<int32_t*>(&x);

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

Функция main выделяет пустое место на своем стеке до вызова make_optional.
Функция main передает адрес этого пустого места как невидимый первый аргумент в регистре %rdi.
Функция make_optional даже не пытается что-то возвращать. Она просто собирает объект напрямую по адресу из %rdi, то есть прямо в памяти вызывающей функции main!

Это называется RVO (Return Value Optimization). В C++ эта оптимизация долгое время зависела от настроения компилятора, и лишь в C++17 стала гарантированной. В AsmX RVO гарантируется на уровне самого ядра кодогенератора. Никаких лишних копирований rep movsb не происходит — данные рождаются сразу там, где они должны жить.

2.10. Исчерпывающий Control Flow и именованные переходы

В ассемблере нет циклов и условий, есть только сравнения (cmp) и переходы (jmp, je, jne). Raptor Engine берет на себя рутину по генерации относительных байтовых смещений.

Язык теперь полностью поддерживает классические конструкции:

if / else
while
return

Но настоящей жемчужиной является система именованных переходов (Labeled Jumps). В C есть оператор goto, который часто ругают за создание «спагетти-кода», так как он позволяет прыгнуть куда угодно, ломая стек. AsmX предлагает элегантный компромисс: вы можете ставить метки только на циклы или блоки, и использовать break или continue с указанием конкретной метки.

goat: while (true) {
  while (true) {
    if (condition) {
      break goat; // Мгновенный выход из ОБОИХ циклов!
    }
  }
}

Компилятор ведет статический стек меток (loopStack). Если вы попытаетесь сделать break на несуществующую метку или вне цикла, компиляция прервется. Это дает мощь goto для сложных системных алгоритмов, но оставляет код полностью предсказуемым и безопасным.

2.11. Интроспекция с нулевой стоимостью: магия sizeof

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

print_number<int32_t>(sizeof(BankCard)); // Выведет 24

Функции sizeof не существует в скомпилированном бинарном файле. Когда семантический анализатор видит этот "вызов", он замораживает процесс, вычисляет размер переданного типа или переменной с учетом всех выравниваний (alignment) и подступов (padding), а затем уничтожает узел вызова в AST, заменяя его на узел числового литерала (например, 24).

Генератор машинного кода видит лишь инструкцию @mov %reg, $24. Стоимость выполнения sizeof в рантайме равна абсолютному нулю.

Глава 3. Практический раздел: Архитектура в действии

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

source syscall_write and strlen

fn strlen(const char* str) -> int32_t {
  int32_t len = 0;
  while (str[len] != 0) {
    len = len + 1;
  }
  return len;
}

fn syscall_write(int32_t fd, const char* buf, int32_t count) -> int32_t {
  @mov $1, %rax;      // номер сисколла sys_write
  @mov $fd, %rdi;     // читаем значение аргумента fd со стека
  @mov $buf, %rsi;    // читаем значение аргумента buf со стека
  @mov $count, %rdx;  // читаем значение аргумента count со стека
  @syscall;
}

// 1. Подключаем стандартную библиотеку для работы с опциональными типами
@include "optional.asmx";

// 2. Объявляем безопасное размеченное объединение (Tagged Union)
union ConfigResult {
  Success(int32_t),
  Error(const char*)
}

// 3. Структура конфигурации с инкапсуляцией
struct ServerConfig {
pub:
  int32_t port;
priv:
  const char* bind_ip;
}

pub constructor ServerConfig::init() {}

// Конструктор
pub constructor ServerConfig::init(int32_t port, const char* ip) -> Self {
  this->port = port;
  this->bind_ip = ip;
  return this;
}

// 4. Логика парсинга
fn parse_port(int32_t raw_input) -> ConfigResult {
  if (raw_input <= 0 || raw_input > 65535) {
    return ConfigResult::Error("Invalid port range");
  }
  return ConfigResult::Success(raw_input);
}

fn main(int32_t argc, char** argv, char** envp) {
  // Вызов парсера
  ConfigResult result = parse_port(8080);

  // 5. Безопасный паттерн-матчинг
  inspect (result) {
    ConfigResult::Success(valid_port) => {
      // Переменная valid_port автоматически извлечена и типизирована!
      ServerConfig srv {};
      srv.init(valid_port, "127.0.0.1");
      
      const char* msg = "Server configured successfully.\n";
      syscall_write(1, msg, strlen(msg));
    }
    ConfigResult::Error(err_msg) => {
      syscall_write(1, "Config Error: ", 14);
      syscall_write(1, err_msg, strlen(err_msg));
      syscall_write(1, "\n", 1);
    }
    _ => {
      // Fallback
    }
  }

  @mov $60, %rax;
  @mov $0, %rdi;
  @syscall;
}

Разбор полётов:

Этот код демонстрирует, насколько далеко ушел AsmX от обычного ассемблера. У нас есть строгая типизация (ConfigResult), есть защита памяти (вы не можете прочитать valid_port, если result содержит ошибку — компилятор физически не сгенерирует такой путь выполнения). Вся абстракция ServerConfig srv {} в итоге "схлопнется" в пару ассемблерных инструкций mov относительно базового регистра %rbp.

Глава 4. Безопасность памяти без рантайм-сборщика

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

В классическом C объединения (union) — это бомба замедленного действия.

union Bad { int i; char* ptr; };
union Bad b;
b.i = 0xDEADBEEF;
printf("%s", b.ptr); // SEGFAULT: Попытка чтения памяти по адресу 0xDEADBEEF

В C компилятор просто накладывает поля друг на друга в одной ячейке памяти. Если вы записали число, а попытались прочитать его как указатель, программа рухнет. Злоумышленники используют это для организации атак типа Type Confusion.

Ответ AsmX — Tagged Unions (Размеченные объединения).

Когда вы пишете union Shape { Circle(int32_t), Rectangle(int32_t, int32_t) }, AsmX неявно добавляет к структуре 4-байтовый тег. В памяти это выглядит так:

[ 4 байта ТЕГ ] [ Выравнивание ] [ Полезная нагрузка ]

Чтобы прочитать данные, вы обязаны использовать конструкцию inspect. inspect генерирует инструкции машинного кода cmp eax, TAG, гарантируя, что код, извлекающий переменные Rectangle, выполнится только в том случае, если в памяти действительно лежит Rectangle. Разработчик физически лишен синтаксической возможности прочитать данные как другой тип.

Безопасность достигается не за счет "сборщика мусора" (как в Go или Java) и не за счет трекинга времени жизни (как Borrow Checker в Rust), а за счет строгой алгебры типов и умной генерации jump-таблиц в ассемблере.

Глава 5. Сравнение AsmX с гигантами индустрии

Чтобы понять нишу AsmX, сравним его с главными инструментами системного программирования: C++ и Rust.

Критерий	C++ (GCC/Clang)	Rust (rustc/LLVM)	AsmX (Raptor Engine)
Парадигма	Мультипарадигменная, акцент на ООП и метапрограммировании.	Функциональная/ООП, акцент на безопасном владении памятью (Ownership).	Процедурная/ООП, акцент на абсолютной прозрачности трансляции в ассемблер.
Runtime (Прослойка)	Тяжелый (libc, статические инициализаторы, RTTI, исключения).	Средний (libcore, panic handlers).	Нулевой. Код исполняется напрямую с точки входа ядра Linux. Никакого `libc`.
Скорость компиляции	Низкая (из-за `#include` и гигантских заголовочных файлов).	Низкая (сложный Borrow Checker и макросы).	Молниеносная. AST Splicing (встраивание деревьев) заменяет текстовый препроцессор.
Управление памятью	Ручное (`new`/`delete`). Высокий риск утечек и Use-After-Free.	Автоматическое на этапе компиляции (Borrow Checker). Очень безопасно.	Ручное. Компилятор гарантирует безопасный доступ (через `inspect` и инкапсуляцию), но не управляет очисткой кучи.
Шаблоны (Generics)	Тьюринг-полное метапрограммирование, чудовищный синтаксис ошибок.	Трейты (Traits), строгие границы типов.	Прямолинейная мономорфизация. Простая подмена AST-токенов "на лету" без абстрактной математики.
Контроль над железом	Ограничен. Необходим `inline assembly` с непредсказуемым синтаксисом ограничений.	Ограничен. Блоки `unsafe { asm!(...) }` сложны в отладке.	Абсолютный. Доступ к инструкциям (`@mov`, `@syscall`) и SIB-адресации встроен в синтаксис языка наравне с `while` и `if`.
Размер бинарника	Большой (мегабайты из-за статической линковки стандартной библиотеки).	Средний/Большой (сотни килобайт минимум).	Микроскопический (измеряется в сотнях байт для простейших программ).

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

Глава 6. Нюансы FFI: Искусство вызова AsmX из языка C

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

Когда мы говорим о прозрачном вызове AsmX из языка C (FFI — Foreign Function Interface), мы сталкиваемся с интересным взаимодействием манглинга имён и архитектуры компилятора.

Рассмотрим пример библиотеки на AsmX:

// AsmX код (libm.asmx)
__share__ fn add() {
  @mov %rdi, %rax;
  @add %rsi, %rax;
}

__share__ fn sub() {
  @mov %rdi, %rax;
  @sub %rsi, %rax;
}

В этом коде функции add и sub не принимают явных высокоуровневых параметров (int32_t a, int32_t b). Они работают напрямую с регистрами %rdi и %rsi. Из-за этого семантический анализатор AsmX видит пустой список аргументов и, даже несмотря на модификатор share, применяет базовый манглинг для функций без аргументов, добавляя суффикс __void.

Таким образом, в сгенерированной библиотеке .so реальные символы будут называться add__void и sub__void.

Чтобы вызвать их из языка C, мы не можем просто написать extern long add(long, long);. Линкер C будет искать точный символ add и упадет с ошибкой undefined reference.

Решение этой проблемы элегантно и демонстрирует гибкость C. Мы используем директиву asm("...") при объявлении внешней функции. Это говорит компилятору C: "В моем C-коде эта функция будет называться add, но когда ты будешь искать её в бинарном файле библиотеки, ищи символ add__void".

// C-код (libm_test.c)
#include <stdio.h>

#ifdef __cplusplus
extern "C" {
#endif

// Связываем C-имя с реальным манглированным символом в .so библиотеке
long add(long a, long b) asm("add__void");
long sub(long a, long b) asm("sub__void");
void lc_print() asm("lc_print__void");

#ifdef __cplusplus
}
#endif

int main() {
  // Вызов работает прозрачно. Аргументы 100 и 20 
  // автоматически лягут в %rdi и %rsi по правилам SysV ABI.
  long res_add = add(100, 20); 
  printf("add(a, b) result: %ld\n", res_add);
  return 0;
}

Модификатор share в сочетании со сборкой в Shared Object (.so) заставляет драйвер AsmX экспортировать эти символы в таблицу динамической линковки (PLT), делая их видимыми для GCC. Это позволяет объединять математическую точность ассемблера с инфраструктурой C/C++.

Глава 7. Путь миграции и совместимость старого кода

Переход на версию компилятора с Raptor Engine — это не просто обновление, это смена парадигмы. Старый код, написанный для предыдущих версий AsmX, потребует адаптации.

Вот полный список изменений, нарушающих обратную совместимость (Breaking Changes), и руководство по миграции:

Комментарии: Все двойные точки с запятой ;; теперь вызывают синтаксическую ошибку. Произведите глобальную автозамену ;; на //.
Вызовы из ассемблерных вставок: Низкоуровневая инструкция @call теперь полностью осведомлена о высокоуровневой семантике. Если вы вызываете внешнюю функцию (например, в разделяемой библиотеке .so), компилятор автоматически сгенерирует релокацию R_X86_64_PLT32 вместо локальной PC32. Рекомендуется заменить @call name; на высокоуровневый вызов name(); везде, где это возможно.
Системные вызовы sys_exit: Компилятор больше не генерирует эпилог sys_exit (прерывание 60) автоматически в конце функции main. Разработчик обязан явно прописать инструкции завершения программы (или вызов функции из libc), иначе процесс завершится аварийно.

Глава 8. Анатомия стандартной библиотеки (std): Шаблоны и примитивы ядра

Полноценная экосистема невозможна без стандартных контейнеров и утилитарных типов. Благодаря мономорфизации AST-деревьев и поддержке модификаторов доступа, в AsmX стало возможным создание безопасных абстракций верхнего уровня с нулевой стоимостью в рантайме. Рассмотрим устройство модулей optional.asmx и pair.asmx.

8.1. Безопасная обработка отсутствия данных: std::optional

В системном программировании на C отсутствие значения часто выражают через NULL (нулевой указатель). Но если функция должна вернуть структуру или примитивный тип (например, int32_t), возвращать 0 как признак ошибки нельзя — ноль может быть валидным результатом вычислений.

Класс-шаблон std::optional управляет опциональным значением (то есть значением, которое может как присутствовать, так и отсутствовать), инкапсулируя флаг валидности и саму полезную нагрузку в единый безопасный объект, избегая необходимости динамического выделения памяти.

Параметры шаблона:

T — Тип инкапсулируемого значения.

Методы структуры (Member functions)

Метод	Сигнатура	Описание
`(constructor)`	`pub constructor init() -> std::optional<T>` `pub constructor init(T val) -> std::optional<T>`	Конструирует объект `optional`. Вызов без аргументов создает объект, не содержащий значения. Вызов с аргументом инициализирует объект переданным значением и выставляет флаг присутствия.
`has_value`	`pub fn has_value() -> bool`	Возвращает `true`, если объект содержит значение, и `false` в противном случае.
`value`	`pub fn value() -> T`	Возвращает инкапсулированное значение. Примечание: перед вызовом разработчик обязан убедиться в наличии значения с помощью `has_value()`.
`value_or`	`pub fn value_or(T default_val) -> T`	Безопасное извлечение. Возвращает содержащееся значение, если оно доступно. Если объект пуст, возвращает переданное резервное значение `default_val`.

Вспомогательные функции (Non-member functions):

make_optional
- Сигнатура: pub fn make_optional(T val) -> std::optional<T>
- Описание: Фабричная функция для удобного создания объекта. Позволяет компилятору (в перспективе) выводить тип T автоматически, создавая инициализированный экземпляр optional через синтаксис списочной инициализации {val}.

8.2. Группировка разнородных данных: std::pair

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

std::pair — это структурный шаблон, который объединяет два значения потенциально разных типов в единый объект.

Параметры шаблона:

T — Тип первого элемента.
U — Тип второго элемента.

Открытые поля данных (Member objects)

В отличие от optional, где внутреннее состояние скрыто модификатором priv, данные в pair спроектированы для прозрачного доступа:

Поле	Тип	Описание
`first`	`T`	Хранит первый элемент пары.
`second`	`U`	Хранит второй элемент пары.

Методы структуры (Member functions)

Метод	Сигнатура	Описание
`(constructor)`	`pub constructor init()` `pub constructor init(T first, U second) -> std::pair<T, U>`	Базовый конструктор выделяет память под кортеж. Конструктор с параметрами инициализирует поля `first` и `second` переданными значениями, возвращая адрес структуры (`this`).
`get_first`	`pub fn get_first() -> T`	Возвращает значение поля `first`.
`get_second`	`pub fn get_second() -> U`	Возвращает значение поля `second`.

Вспомогательные функции (Non-member functions)

make_pair
- Сигнатура: pub fn make_pair(T first, U second) -> std::pair<T, U>
- Описание: Фабричный хелпер для быстрого конструирования пары. Благодаря поддержке списочной инициализации и механизму SRET (Struct Return), вызов этой функции способен размещать данные напрямую в памяти вызывающего контекста, избегая накладных расходов на копирование регистров для структур размером более 16 байт.

// Инициализация базовых данных
int32_t x = 2026;

// Пример 1: Упаковка указателя в опциональный контейнер
std::optional<int32_t*> ptr_opt = std::make_optional<int32_t*>(&x);

// Пример 2: Формирование пары "ключ-значение" из константной строки и указателя
std::pair<const char*, int32_t*> card = std::make_pair<const char*, int32_t*>("year", &x);

Глава 9. Заключение и дорожная карта (Roadmap)

Внедрение Raptor Engine переводит AsmX в статус серьезных инструментов для системного программирования. Полноценный анализ Абстрактного Синтаксического Дерева, реализация RVO, SRET, шаблонов-мономорфов и паттерн-матчинга — это колоссальный скачок.

Куда проект движется дальше?

Реализация стандартной библиотеки (stdlib): Текущий релиз закладывает фундамент (std::optional, std::pair). Следующим шагом станет реализация полноценных динамических коллекций, требующих интеграции с аллокаторами памяти (например, malloc/free).

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

компилятор построен из 30к строк кода (.js, .ts, .cts, .asmx)
Git diff: 43 files changed +12,989-849 Lines changed: 12989 additions & 849 deletions
GitHub: https://github.com/AsmXFoundation/AsmX-G3
Если статья вдохновила вас на новые проекты в низкоуровневом программировании, поделитесь ею с коллегами!

AsmX с движком Raptor: Архитектура абсолютного контроля