A programming language that brings high-level code, secure boundaries, low-level control, and native execution into one model

Documentation + Installation + Quick Start + VS Code Extension + Benchmarks + Contributing

X is designed so code can be read directly from program intent while still reaching memory, syscalls, FFI, and native output when needed. The key point is allowing high-level and low-level code to live together without hiding ownership or safety boundaries behind the runtime.

Why X Is Different

• Memory modes: @high, @secure, and @low change the rules for the source that follows them. They are not annotations that affect only one line.
• Formula numeric spaces: low-level code can write numeric widths directly with num[bits], numu[bits], and numf[bits] instead of relying on a fixed list of type names.
• Human-first syntax: Names like say, listen, track, pulse, and drift are quick to read from intent, without forcing beginners to learn technical terms first.
• One source, two execution paths: The same source can run through XVM and can also be built into a native executable.
• Direct native emitter: The AOT path in X creates native output directly for supported targets. It does not start by translating through a C backend or LLVM.
• Native boundary, not platform-format-first design: link native defines the library name and symbol to call without tying the language concept to any single file extension.
• XEE runtime entropy: Random generation is handled by a layered entropy engine with timing-jitter collection, source health checks, conservative evidence gates, ARX output generation, and fast runtime access.
• Real system access: fux!, syscalls, sized numbers, native linking, and shared-library export live on the same path as the main language.

One File Can Move Across Levels

X is designed so readable code and code that touches the real system can exist in the same language. fux! keeps low-level code scoped while normal code stays readable.

fux! main() {
    say("X can stay readable")
    syscall(7, "X can still touch the system")
}

Installation

Windows

Download a Windows release from GitHub Releases:

• x<version>.windows-amd64.msi installs X for the current user and adds it to PATH.
• x<version>.windows-amd64.machine.msi installs X for all users and adds it to the system PATH.
• x<version>.windows-amd64.zip is the portable archive. Extract it, then add its bin folder to PATH.

Linux

Download the Linux release from GitHub Releases:

• x<version>.linux-amd64.tar.gz is the portable archive. Extract it, then add its bin folder to PATH.

After installation, open a new terminal and run:

x --version
x version list
x help

The installed files form a local toolchain root:

bin/
  x[.exe]
active
versions/
  <version>/
    bin/
      x[.exe]
    stdlib/

The launcher in bin/ stays in PATH. It selects a version from x.config first, then the local active file. Projects can lock the compiler with:

+ x
    version: "0.1.0"
    std: "stable"

Use x version use <version> to switch the active local version.

Editor Support

Install the X VS Code Extension for syntax highlighting, IntelliSense, diagnostics, and running .x files from Visual Studio Code.

Building from Source

Build the release binary:

Run the built binary directly:

target\release\x.exe hello.x

Add the release binary directory to PATH if you want to use x from any project folder.

Quick Start

Create hello.x

Create x.config

+ project
	name: "myproject"
	version: "0.1.0"
	main: "hello.x"

Run a file:

Run the project entry from x.config:

Build a native executable:

Build a shared native library:

x build native_api.x --shared --output build/native_api.dll --header build/native_api.h --def build/native_api.def --abi build/native_api.xabi.json

Core Ideas

Memory Modes

X memory modes are applied in source order. The default mode is @high; after declaring @secure or @low, the code that follows is under that mode's rules until a new mode is declared.

@secure

shape Credential {
    token: txt

    fux check(candidate: txt): bit {
        return match_secret(token, candidate)
    }
}

@high

fux main() {
    var credential = Credential("vault-token")
    var sealed = to_secure(credential)

    say(sealed.check("vault-token"))
}

fux! is used for low-level fuxions with a clear scope, without leaving @low open across the whole file.

Formula Numeric Spaces

X does not grow numeric type names one by one. Numeric width is written directly in the type.

fux! main() {
    var byte: numu[8] = 255
    var color: numu[24] = 16777215
    var exact: numu[64] = 9007199254740993
    var signed: num[32] = -1
    var real: numf[64] = 3.14
    var exact_real: numf[128] = 0.1 + 0.2

    say(exact)
    say(exact_real)
}

This keeps low-level numeric layout explicit without expanding the language with a fixed list of aliases. Integer spaces use exact sized integer values. Non-native numf[bits] values use X's soft-float value engine: literals and arithmetic are stored as exact finite rational values, then rendered to decimal through the declared width instead of being reduced to host f64 first.

The numeric_formula benchmark runs numu[64] arithmetic above 2^53 with exact integer behavior: 1.14us median, 1.31us p95.

Control Syntax

track selects a path from a value, condition, or result. pulse is used for loops, and rush can mark that loop as a performance-sensitive path.

var names = ["first", "second", "third"]

track names[1] {
    "first" : say("found")
    drift   : say("missing")
}

var i = 0
rush pulse(i < 1000) {
    i = i + 1
}

X arrays start at index 1.

Native Pipeline

The X pipeline lowers source into AST, XLIR, and XVM bytecode before running through XVM or building native output.

.x source -> AST -> XLIR -> XVM bytecode -> optimizer -> XVM / AOT

Omnipath

Omnipath is the native execution path inside XVM for code that starts by running through the interpreter and is lifted when a loop becomes hot. XVM counts fuxion backedges, stores the native entry in a cache, and calls that entry directly on later iterations.

In the XVM path, this connects to the native emitter, native syscall dispatcher, interpreter thunk, and helpers for loop forms known by the optimizer, such as numeric loops, count loops, and XEE random calls.

FFI

X FFI is a native boundary: X code can call native libraries through link native, and X code can also be built as a shared native library for other systems to call.

The syntax is the same across native targets. The library name is the platform library file that the selected target can load.

link native "kernel32.dll" {
    get_tick_count(): numu[32] = "GetTickCount"
}

fux! main() {
    say(get_tick_count())
}

For Linux targets the same form can point to a shared object:

link native "libc.so.6" {
    text_length(text: txt): numu[64] = "strlen"
}

Runtime Services

XVM has runtime services for IO, filesystem, process, network, memory, syscalls, and random generation through XEE.

Zero-Copy Source Path

The X lexer stores token lexemes with Cow<'source, str> and source spans so normal tokens can borrow slices directly from the original source. String escapes, interpolation, and numbers with suffixes allocate only when a new value must be created.

For memory modes, this means the front-end does not need to copy many identifiers, keywords, and literals before reaching the analyzer. The @high, @secure, and @low modes are checked from tokens and spans that point back to the original source, so mode rules, diagnostics, and semantic checks work on the same source-backed data from lexer to analyzer.

XEE: Runtime Entropy Engine

XEE is the entropy and random-generation subsystem inside XVM. It is built as a pipeline instead of a single random call: timing jitter is collected, conditioned, mixed through a chaos amplifier, absorbed into an entropy pool, used to rekey an ARX-based core, and served through a burst buffer for repeated reads.

timing jitter -> conditioned signal -> chaos amplifier -> entropy pool -> ARX core -> burst buffer

The harvester collects CPU timing jitter as XEE source material. Each 64-bit harvest word is built from multiple timing samples around a data-dependent work function, memory/cache timing probes, differential timing signals, and online source health checks.

XEE also includes an evidence layer. The proof gate does not grant entropy credit just because final bytes look uniform; it checks observed source behavior before and during conditioning, applies health gates, caps credit per sample, and reports explicit evidence levels such as rejected, statistical_only, physical_jitter_observed, and physical_jitter_conditioned.

What XEE exposes today:

• std.random fuxions: random, random_between, random_decimal, and random_bytes.
• Runtime and native paths for 64-bit engine output, bounded ranges, decimal output, and bulk byte filling.
• Health counters for observed samples, repetition-count failures, adaptive-proportion failures, current repetition run, and the latest adaptive window.
• Validation helpers for byte distribution, bit balance, runs, duplicate pressure, lag-1 serial correlation, birthday spacings, and binary matrix rank.
• Official NIST SP 800-90B non-IID evidence through the ea_non_iid tool. xee_bench writes the byte sample file, runs the official tool, parses the reported min-entropy, and uses that result as an evidence gate.

These are implementation and measurement facts, not a certification claim. XEE includes tests, health snapshots, proof gates, and benchmark evidence for the source behavior and generated output.

Benchmarks

These numbers come from local Windows amd64 release runs. Tables report medians across repeated samples where available, so one slow or fast run does not decide the published number. They are benchmark evidence for this machine and this commit state, not a certification claim.

Benchmark Summary

Commands used:

Windows

.\tools\run_benchmarks.ps1 -XeeTool "C:\path\to\ea_non_iid.exe"

Linux

chmod +x tools/run_benchmark.sh
./tools/run_benchmark.sh /path/to/ea_non_iid.exe

XVM Execution

Host stabilization was enabled with Windows high process priority and highest thread priority. Execute timing uses auto batching with a 2 ms target. Each row reports the median value across five reports.

XEE Evidence

This is the full xee_bench report data from the official NIST run saved at target/xee_bench/official_real/strict_report.json.

XEE Raw Jitter Audit

XEE Output Audit

XEE Proof Gate

Official NIST SP 800-90B

XEE Throughput

License

X Programming Language is created and maintained by X XXX.

Released under the 0BSD license. You can use, copy, modify, distribute, and sell it without attribution requirements.

Documentation

Read more about syntax, memory modes, secure mode, the low-level API, stdlib, and AOT in the Documentation.