AsmX Raptor: Natywny asembler i ścisła typizacja w programowaniu systemowym

AsmX Raptor: Rewolucja w programowaniu systemowym dzięki natywnemu asemblerowi i ścisłej typizacji

Programowanie systemowe tradycyjnie mierzy się z dylematem: albo pełna kontrola nad sprzętem kosztem wysokich abstrakcji i złożoności utrzymania, albo wygoda języków wysokiego poziomu z utratą bezpośredniego dostępu do sprzętu. Technologia AsmX Raptor oferuje radykalne rozwiązanie, integrując instrukcje asemblera bezpośrednio w abstrakcyjne drzewo składniowe (AST) kompilatora. To podejście pozwala programistom manipulować rejestrami i wykonywać specyficzne instrukcje CPU, jednocześnie wykorzystując potężny system typów i nowoczesne narzędzia do analizy statycznej, co wcześniej było niemożliwe bez kompromisów.

Problem: Kompromisy w programowaniu systemowym i bolączki `inline asm`

Programiści tworzący krytyczne oprogramowanie systemowe, takie jak systemy operacyjne, sterowniki urządzeń czy hiperwizory, pilnie potrzebują bezpośredniego dostępu do rejestrów CPU, wyspecjalizowanych instrukcji (np. cpuid, rdtsc, wrmsr) oraz precyzyjnej kontroli nad stosem. Współczesne narzędzia oferują kilka ścieżek, z których każda wiąże się ze znaczącymi wadami:

Czysty asembler (NASM/GAS): Zapewnia absolutną kontrolę, ale całkowicie pozbawia programistę zalet języków wysokiego poziomu, takich jak system typów, struktury danych, zakresy widoczności i łatwość utrzymania kodu. Pisanie złożonej logiki biznesowej staje się pracochłonnym, ręcznym zarządzaniem pamięcią i rejestrami.
Oddzielna kompilacja (C/C++ + pliki obiektowe ASM): Oznacza tworzenie oddzielnych plików .asm, ich kompilację i późniejsze linkowanie z kodem wysokiego poziomu. Metoda ta wprowadza narzut związany z koniecznością ścisłego przestrzegania ABI (np. System V AMD64), kosztami cykli procesora na prolog/epilog funkcji i zachowanie rejestrów, co prowadzi do nieefektywnych przejść i zbędnych obiektów.
C/C++ z inline assembly (__asm__): Najbardziej rozpowszechnione, ale i najbardziej problematyczne podejście. inline asm jest faktycznie "czarną skrzynką" dla kompilatora, niszczącą wiele optymalizacji i abstrakcji:

* Ciągowe piekło: Kod asemblerowy jest osadzany jako literały ciągów znaków, co pozbawia programistę autouzupełniania, statycznej weryfikacji składni i odpowiedniego podświetlania w IDE.

* Kruche ograniczenia (Fragile Constraints): Nieprawidłowo określone ograniczenia (np. =r zamiast +m) mogą prowadzić do generowania niepoprawnego kodu maszynowego, który ujawni się dopiero w czasie działania w postaci trudnych do wykrycia "Heisenbugów".

* Niszczenie potoku optymalizatora: Dla kompilatora blok inline asm to nieprzejrzysta plama. Optymalizator nie może analizować ani zmieniać kolejności instrukcji wewnątrz tego bloku, co może prowadzić do nieefektywnego kodu lub naruszenia logiki, jeśli instrukcje przed lub po bloku zostaną przestawione. Kompilator często asekuruje się, zachowując zbędne rejestry, nawet jeśli nie są używane.

* Powiązanie z backendem: Zachowanie i składnia ograniczeń inline asm są często specyficzne dla konkretnych wersji kompilatorów i architektur.

Istota problemu polega na tym, że asembler nie powinien być "wstawką". Powinien być pełnoprawnym komponentem języka, zintegrowanym na poziomie kompilatora.

AsmX Raptor: Integracja asemblera w AST

AsmX Raptor fundamentalnie zmienia podejście do pracy z asemblerem, czyniąc go natywnym "tokenem" języka. Oznacza to, że instrukcje maszynowe i deklaracje typów wysokiego poziomu istnieją w jednym drzewie składniowym (AST). Kompilator AsmX Raptor nie tylko tłumaczy mnemoniki, on rozumie semantykę twoich działań z rejestrami i typami jednocześnie. Eliminuje to potrzebę wstawek tekstowych i związanych z nimi problemów. Rozważmy przykład:

fn foo_int32_t(int32_t, int32_t) -> int32_t {
 ;; code
}

fn main {
  @mov $0, %rdi;
  @add $10, %rdi;
  @cmp $0, %rdi;

 ;; Pełne wsparcie dla kwalifikatorów CV i typowania w tym samym zakresie!
  const int32_t* dotw1 = nullptr;
  const volatile int32_t* const volatile dotw12 = nullptr;
  int32_t volatile * const dotw18 = nullptr;
  
  const char* str = "string";
  const int32_t& addrof = ch0;
  bool b3 = 1 > 3;
  int32_t (*funcPtr)(int32_t, int32_t) = foo_int32_t;
  
  int16_t casted = reinterpret_cast<int16_t>(43);
  
  @syscall($1, $1, &message, $13);
  @call somefunc
  @mov $60, %rax
  @mov $0, %rdi
  @syscall
}

W tym kodzie @mov i const int32_t* są przetwarzane przez to samo jądro kompilatora. Takie podejście pozwala stosować do instrukcji asemblera te same mechanizmy analizy statycznej, sprawdzania typów i optymalizacji, co do kodu wysokiego poziomu. Zapewnia to bezprecedensowy poziom kontroli i bezpieczeństwa podczas tworzenia oprogramowania systemowego.

Architektura kompilatora: Wielopoziomowy potok AsmX Raptor

Przejście na AsmX Raptor zapoczątkowało fundamentalną zmianę architektoniczną w kompilatorze. Od starego, "płaskiego" podejścia, gdzie lekser bezpośrednio przekazywał tokeny parserowi do generowania płaskiej listy instrukcji, Raptor przeszedł do ścisłej, wielopoziomowej architektury kompilacji, zapewniającej głęboką analizę statyczną i wieloprzebiegowe optymalizacje:

Transformer V2 (Inteligentne preprocesowanie): Odpowiada za prenormalizację tokenów i rozwiązywanie złożonych konstrukcji leksykalnych, wykorzystując logikę lookahead do poprawnej interpretacji.
Pratt Parser: Łączy rekurencyjne zejście z algorytmem stacji sortującej (Precedence Climbing) w celu efektywnego budowania ściśle typizowanego abstrakcyjnego drzewa składniowego (AST). Pozwala to poprawnie przetwarzać operatory o różnym priorytecie i asocjatywności.
Semantic Analyzer: Wykonuje proaktywną walidację kodu. Przechodzi przez AST, przeprowadzając sprawdzanie typów (QualType), zarządzanie zakresami widoczności (Scope) i rozwiązywanie symboli. Ten etap jest krytyczny, ponieważ wykrywa błędy logiczne i niezgodności typów przed generowaniem kodu maszynowego, co znacząco zwiększa niezawodność.
Compiler Driver (Raptor): Działa jako "most abstrakcji", łącząc AST wysokiego poziomu z niskopoziomową reprezentacją sprzętową poprzez wzorzec "Operand Bridge". Pozwala to kompilatorowi efektywnie tłumaczyć semantycznie sprawdzone AST na zoptymalizowany kod maszynowy.

Dzięki temu potokowi, AsmX Raptor jest w stanie nie tylko tłumaczyć mnemoniki, ale także głęboko rozumieć kod, zapewniając kompleksową analizę i optymalizację.

Ewolucja systemu typów: Ścisłe reguły i jawne intencje

W AsmX Raptor system typów został całkowicie przebudowany od podstaw, czerpiąc z potęgi C++, ale unikając jego historycznego bagażu. Teraz kompilator "domyślnie" rozumie podstawowe typy, takie jak int16_t, int32_t, bool, char i wskaźniki, przechowując je w tabeli typów podstawowych. Pozwala to na wdrożenie ścisłej kontroli typów i zapewnienie bezpieczeństwa na poziomie systemowym.

Prawdziwy `nullptr`

W przeciwieństwie do C i wczesnego C++, gdzie NULL był makrem, rozwijającym się do 0 i prowadzącym do błędów przy przeciążaniu funkcji, w Raptorze nullptr jest samodzielnym typem prymitywnym. Analizator semantyczny gwarantuje, że nullptr może inicjalizować tylko wskaźniki, zapobiegając nieprawidłowemu użyciu:

const int32_t* p = nullptr; // OK: wskaźnik akceptuje nullptr
const int32_t p = nullptr;  // Błąd kompilacji

Przy próbie inicjalizacji typu niebędącego wskaźnikiem za pomocą nullptr zostanie zgłoszony błąd kompilacji:

[ExpressionException]: [błąd typu] nie można zainicjalizować 'const int32_t' za pomocą nullptr: nie jest to typ wskaźnikowy
95 |	
96 |	 const int32_t p = nullptr;
97 |	 ^-------------------------

Kwalifikatory CV i ochrona LValue

Język AsmX Raptor natywnie rozumie const i volatile, przechowując je jako właściwości wewnątrz opakowania QualType. Analizator semantyczny aktywnie zapobiega próbom przypisania wartości do read-only lvalue (stałych), zapewniając bezpieczeństwo i przewidywalność:

const char char_a = 'a';
char_a = 'd';

Taka próba doprowadzi do błędu:

[ExpressionException]: [błąd typu] nie można przypisać do lvalue kwalifikowanego jako const
85 |	
86 |	 char_a = 'd';
87 |	 ^-------------

Ścisłe rzutowania i zwijanie referencji (Reference Collapsing)

W Raptorze zaimplementowano ścisłe reguły zwijania dla typów referencyjnych (Reference Collapsing), co stanowi fundament dla przyszłej integracji zaawansowanego zarządzania pamięcią i semantyki przenoszenia. Próby powiązania referencji niebędącej const z obiektem tymczasowym lub niezgodnym typem wywołają błąd kontekstowy:

[ExpressionException]: [błąd typu] nie można powiązać referencji lvalue niebędącej const 'const int32_t&' z wartością typu 'const char*'; nie można utworzyć obiektu tymczasowego dla referencji niebędącej const
95 |	
96 |	 const int32_t& ref = str;
97 |	 ^------------------------

System rzutowania również został przeprojektowany: brak niejawnych konwersji wskaźników na liczby całkowite. Jawne intencje są wyrażane poprzez węzły ImplicitCastExpression w AST. To sprawia, że niskopoziomowa magia z pamięcią staje się przejrzysta i kontrolowana:

const_cast<T>: Stosowany tylko do wskaźników i referencji w celu dodania/usunięcia kwalifikatorów CV.

```

[ExpressionException]: [błąd typu] nieprawidłowy const_cast: const_cast może być używany tylko ze wskaźnikami lub referencjami

72 | int16_t casted = const_cast<int32_t>(2026);

73 | ^-------------------------

```

static_cast<T>: Wykonuje standardowe konwersje ze sprawdzaniem rozmiarów typów poprzez AnyType.size().

```

int32_t casted = static_cast<int16_t>(43); // OK

int16_t casted = static_cast<int16_t>(43); // OK

```

[ExpressionException]: [błąd typu] nie można zainicjalizować 'int16_t' za pomocą 'int32_t'

72 | int16_t casted = static_cast<int32_t>(2026);

73 | ^-------------------------

```

reinterpret_cast<T>: Zapewnia niskopoziomowe "drzwi awaryjne" do surowego rzutowania pamięci (pointer punning), tymczasowo wyłączając system typów dla konkretnego bloku. Jego użycie wyraźnie sygnalizuje potencjalnie niebezpieczne operacje.

Inicjalizacja danych i funkcje z typizacją

W programowaniu systemowym kluczowe jest precyzyjne rozmieszczenie danych w pliku binarnym. AsmX Raptor oferuje przeprojektowaną składnię do pracy z sekcjami (.rodata, .data), która obejmuje ścisłą kontrolę typów (type-checker) podczas inicjalizacji zmiennych:

@section rodata {
  integer: int32_t(1);
  message: const_cast<const char*>("Hello World!\n");
}

@section data {
  call: const_cast<char*>("call from the somefunc\n");
}

Jeśli zostanie użyty typ, który nie został jeszcze zarejestrowany w jądrze kompilatora, parser AST natychmiast zatrzyma kompilację, wyświetlając czytelne komunikaty o błędach, wskazujące na konkretną linię i problematyczny token:

[ExpressionException]: Nieznana nazwa typu 'int8_t'
4 |	
5 |  some_int: int8_t(1);
6 |            ^---------

Wprowadzenie ścisłej typizacji całkowicie zmieniło również podejście do deklarowania funkcji. Drzewo AST teraz waliduje typy argumentów i zwracaną wartość. Na przykład wywołanie systemowe:

fn syscall_write(int32_t fd, const char* buf, int32_t count) -> int32_t {
  @mov $1, %rax;
  @syscall;
}

Tutaj int32_t i const char* to nie tylko tekst, ale w pełni typizowane parametry, co stanowi podstawę dla przyszłego wsparcia przeciążania funkcji i ścisłej walidacji argumentów podczas wywołania.

Niezależna kompilacja modułów jądra Linux

Jedną z najważniejszych systemowych innowacji AsmX Raptor jest możliwość syntezy dynamicznych modułów jądra Linux (.ko) bez zależności od konkretnej wersji jądra (Version-Agnostic). W poprzednich wersjach kompilatora używano "sztywno zakodowanych" przesunięć struktur jądra, co czyniło go niezwykle kruchym i zależnym od wersji jądra (np. 6.17.9-arch1-1).

AsmX Raptor rozwiązuje ten problem, zapewniając kompatybilność z każdą wersją jądra Linux. Osiąga się to dzięki głębszemu zrozumieniu architektury jądra oraz dynamicznemu rozwiązywaniu symboli i struktur, co znacznie upraszcza rozwój i utrzymanie modułów jądra, zwiększając ich przenośność i niezawodność.

Co ważne:

AsmX Raptor integruje instrukcje asemblera bezpośrednio w AST, eliminując wady inline asm i zapewniając kontrolę na poziomie kompilatora.
Nowa, wielopoziomowa architektura kompilatora (Transformer V2, Pratt Parser, Semantic Analyzer) umożliwia przeprowadzanie głębokiej analizy statycznej i optymalizacji.
Przeprojektowany system typów z prawdziwym nullptr, kwalifikatorami CV i ścisłymi rzutowaniami zwiększa bezpieczeństwo i przewidywalność kodu systemowego.
Typizowana inicjalizacja danych w sekcjach oraz deklaracje funkcji z parametrami i wartościami zwracanymi poprawiają strukturalizację i weryfikowalność kodu.
Możliwość kompilacji modułów jądra Linux (.ko) bez zależności od konkretnej wersji jądra (Version-Agnostic) znacznie upraszcza rozwój sterowników i komponentów systemowych.

— Editorial Team