If you have ever tried to write a lightweight UEFI application or a custom bootloader, you probably know the friction involved.
You either wrestle with the massive, convoluted build system of EDK II, or you spend hours tweaking fragile linker scripts just to force a standard C/Rust compiler to output a valid PE32+ image. Traditional toolchains are built on a philosophy of separation: the compiler handles the logic, and the linker handles the physical geometry.
But in bare-metal environments, physical geometry is logic.
I wanted a toolchain that deeply understands the binary format it is producing, without the historical baggage of POSIX or traditional build systems. So, I started building Aethelium—a system language and "kernel forge" designed exclusively for bare-metal and UEFI development.
Not for your Host OS (The "Compiler Strike")
Before getting into the architecture, I should clarify what Aethelium is not. It does not target macOS, Linux, or Windows. It does not generate ELF or Mach-O executables for your host machine.
It is so strictly separated from the traditional OS ecosystem that if you try to pull in C-style legacy code like #include <stdio.h> or call malloc(), the compiler physically intercepts the token, prints [COMPILER STRIKE] The paradigm barrier starts here, and terminates with exit code 1010.
It is designed from the ground up to target raw x86 silicon and UEFI firmware.
Bypassing the Linker: The "Weaver-Filler" Architecture
In a traditional pipeline (Compiler -> Assembler -> Linker), the compiler generates intermediate object files, leaving the linker to "guess" where the code should go based on abstract symbols. This creates unnecessary friction when all you need is a raw binary payload or a specific EFI header.
Aethelium completely drops the assembler and the linker. Instead, it uses a dual-engine architecture in a single pass:
1. The Weaver: Before a single line of logic is translated, the Weaver pre-calculates the entire physical "skeleton" of the binary. It manually constructs the PE32+ headers, section alignments, base relocations, and fixed memory slots.
2. The Filler: The compiler frontend then lowers the AST and encodes raw x86-64 machine code (handling REX prefixes and ModR/M bytes directly in C) directly into these pre-calculated physical offsets.
Hardware as a First-Class Citizen
Because Aethelium is deeply tied to the metal, hardware constraints are baked directly into the language grammar. You don't need __attribute__((...)) hacks or opaque inline assembly blocks.
Here is what a bare-metal UEFI entry point looks like:
// =========================================================
// Aethelium UEFI Entry Point
// =========================================================
// Direct entry point with gate-specific calling conventions
@entry
@gate(type: \efi)
func efi/main(image/handle: ptr<Void>, sys/table: ptr<EFI/SystemTable>) : UInt64 {
// The compiler natively understands the UEFI ConOut protocol
print("Hello, Bare-Metal World!")
// First-class Hardware block:
// Direct processor state control. The compiler emits raw opcodes here.
hardware {
loop {
hardware\isa\pause()
}
}
return 0 // EFI/SUCCESS
}
Navigable Namespaces
One of the more opinionated design choices in the language is the strict rejection of flat namespaces. Instead of snake_case with underscores (e.g., sys_cpu_id), Aethelium uses / for namespaces (e.g., sys/cpu/id).
It treats system capabilities as a navigable, hierarchical tree. To accommodate this logically at the lexer level, mathematical division uses the ÷ operator. It’s a controversial shift, but it fundamentally changes how you architect low-level APIs.
The Current State
Aethelium is currently a self-hosted bootstrap effort written entirely in C and
assembly. It is fully capable of producing zero-dependency, zero-bloat UEFI "Hello World" binaries, performing hardware state snapshots, and directly probing VGA/COM1 ports without any external dependencies.
If you are interested in compiler architecture, manual x86 opcode encoding, or how to manually construct PE32+/ISO files from scratch in memory, the complete source code of the compiler is open.
You can explore the raw plumbing here:
Aethel-Systems
/
Aethelium
Aethelium: A hardware-first, runtime-less language for modern systems programming. Bypassing linkers and bulky frameworks to emit UEFI and bare-metal binaries directly.
Aethelium: A Hardware-First, Runtime-Less Systems Language Toolchain
A hardware-first, runtime-less systems language toolchain built for modern low-level programming.
Aethelium is an independent, self-contained systems programming language toolchain. It bypasses the cumbersome traditional "compiler-assembler-linker" workflow, focusing on providing an ultra-streamlined build solution for UEFI environments and bare-metal development.
This repository contains the Bootstrap Core of Aethelium. It is capable of generating native machine code or UEFI PE executables for target architectures directly on a host machine (macOS/Linux), without relying on standard object files (.obj/.o) or external linkers.
🏗 Core Architecture
Aethelium utilizes a unique "Weaver-Filler" dual-engine architecture, achieving a direct mapping from high-level semantics to silicon logic:
-
Binary Weaver (
toolsASM) Responsible for the physical orchestration of the low-level binary layout. -
Logic Filler (
toolsC) A compiler frontend implemented in C. It handles semantic analysis and AST construction for Aethelium syntax, precisely…
Top comments (0)