rul .rl
[0x00..0x3F] magic = b"RUL\x00\x01\x00\x00\x00" · 128 位二进制中间表示
Release v0.4.0 (2026-11-07) ↗

面向 AI 智能体的 128 位二进制 编程语言。

AI 用数字思考，CPU 用二进制运行——但 C、Go 和 Rust 却强迫 AI 拼写人类文本，再耗费数秒等待编译器猜测意图。Rul (.rl) 彻底砍掉了文本中间商：AI 直接生成固定的 16 字节二进制积木，自带算法、CPU 调度策略与内存安全票据。结果：5.8 纳秒完成安全验证，6.4 微秒编译出独立程序，运行速度比手写 C 快 4.72 倍。

10 秒读懂第一性原理 · 砍掉人类文本中间商
✗ 传统方式 (C / Go / Rust) AI 思考 (数字) → 拼写人类文本 → 编译器解析语法并猜测意图 (耗时数秒) → 机器码 (0/1)
✓ RUL (.rl) 第一性原理 AI 思考 (数字) → 直接输出 16 字节二进制块 (5.8 ns 验证 + 6.4 µs 编译) → 比 C 快 4.72 倍
16 字节二进制块 (0ms 文本解析) + 6.4 µs 原生 ELF64 (零 LLVM 依赖) + 5.8 ns 安全证明 (O(N) 线性扫描)
# 1. Install standalone rul binary (0 rustc/LLVM runtime deps)
$ curl -fsSL https://raw.githubusercontent.com/rul-lang/rul/main/install.sh | sh

# 2. Scaffold, O(N) verify in ~5.8ns/node, compile 817B ELF64 & trace
$ rul new my-ai-pipeline && cd my-ai-pipeline
$ rul check   # ✓ Verified 7 SSA nodes in 0.04 µs (CAP_NONE = 0x0)
$ rul run     # ✓ Compiled 817-byte ELF64 in 6.4 µs -> Output: 77999800.0
$ rul trace   # ✓ White-Box Inspector: #0..#6 (NaN/Inf = 0)
解剖 16 字节指令帧 ↓ 阅读 v0.4 规范 白皮书 (DOI) ↗
实时 .RL 二进制镜像 · 7 个 SSA 节点 = 208 字节 -> 817 字节 ELF64 CAP_NONE=0x0

点击下方任意 16 字节指令帧，实时解码其比特位、验证器安全证明与执行追踪：

RulHeader
64 Bytes (0x00..0x3F)
Arena[0] + Proof[0]
32 Bytes (0x40..0x5F)
NodeFrame[0..6]
112 Bytes (7 × 16B)
#0 ArenaInput
01 18 11 00
#1 ConstF64
02 11 11 00
#2 CmpGt
14 38 11 00
#3 Mul
12 18 12 00
#4 SelectZero
15 18 11 00
#5 ReduceSum
21 11 11 00
#6 AssertContract
40 11 11 00
Artifact (.rl) = Algorithm + Schedule + Proof ✓ 5.78 ns/node
[0x40] 128 位指令帧
16 字节

每条指令都是固定二进制积木 · 0 ms 文本解析开销

[0x50] 每条指令
5.78 ns

极速内存所有权与边界证明（单遍 O(N) 扫描）

[0x60] 原生编译
6.4 µs

无需 LLVM 直接生成独立 Linux x86_64 ELF64 可执行文件

[0x70] 比 C 快 4.72x
51.53 GB/s

仅修改 1 个字节即可加速 1000 万个浮点数（80 MB）处理

[0x80] 交互式 128 位二进制工作台

一条 16 字节指令 = 算法 + 硬件调度 + 安全证明

选择任意指令节点 (#0..#6) 或点击任意字节 (0..15)，检查其 8 位二进制寄存器、O(N) 安全不变量与白盒执行追踪。

算法通道（算什么：操作码 / 操作数） 调度通道（怎么跑：SIMD / 多核并行） 证明通道（安全保障：版本票据 / 边界证书）
NODE #3 ($n3) node $n3 = Mul f64x8 fg=1 pol=simd proof=0 tok=pure a=$n0 b=$n0
16 BYTES = 128 BITS
8 位寄存器比特分解 · BYTE 2 (b16..b23) 0x12
0 2^7
0 2^6
0 2^5
1 2^4
0 2^3
0 2^2
1 2^1
0 2^0
字段: schedule_hint 类型: u8
✓ 加载时检查的 O(N) 验证器不变量 (~5.78 ns) (fusion_group << 4) | exec_policy

正交硬件调度字节：将 0x11 (SimdStream) 突变为 0x12 (MultiCore) 可切换多核执行而不改变安全证明。

节点 #3: 在 L1 缓存寄存器中融合执行的逐元素 8 通道向量平方 ($n0 * $n0)，零中间堆内存分配。
符号汇编视图 (src/main.rls — .rl 中仅占 208 字节) ~8.8 µs assemble
cap 0x0
arena 0 len=4096 lane=f64x8 mut=false align=64 ver=1
output $n6
白盒执行追踪器 (rul trace — 7 个 SSA 节点) 点击任意行以同步上方 16 字节二进制帧与符号汇编
NODEOPCODEKINDLENMINMAXSUM/TRUESNANSAMPLE[0..4]
#0ArenaInputColumnF6440960.5000249.5000504608.00000[0.500, 1.500, 2.500, 3.500]
#1ConstF64Scalar1100.0000100.0000100.00000[100.000]
#2CmpGtColumnMask40960.00001.00002400.00000[0.000, 0.000, 0.000, 0.000]
#3MulColumnF6440960.250062250.250083627904.00000[0.250, 2.250, 6.250, 12.250]
#4SelectZeroColumnF6440960.000062250.250077999800.00000[0.000, 0.000, 0.000, 0.000]
#5ReduceSumScalar177999800.000077999800.000077999800.00000[77999800.000]
#6AssertContractScalar177999800.000077999800.000077999800.00000[77999800.000]
[0x100] 单字节硬件调度突变

仅修改 1 个字节（Byte 2），速度超越手写 C 语言 4.72 倍。

真实负载：10,000,000 个浮点数（80 MB 数组）——过滤 > 1000.0 的值、平方并求和。点击下方切换第 2 字节 (schedule_hint)：算法逻辑 100% 不变，耗时从 5.91 ms 降至 1.55 ms：

当前第 2 字节 (schedule_hint): 0x12 + ZM bits[16..23] = 0001 0010
1.55 ms · 51.53 GB/s (4.72x vs C)

fg=1 pol=multicore + ArenaZoneMap: 结合多核 L1 分块与块级最小/最大元数据 (ArenaZoneMap)，在 O(1) 时间内直接跳过不满足过滤条件的冷数据块。

[A] 传统命令式 AoS + Vec::collect()
70.66 ms 1.13 GB/s
[B] 标准 Rust SoA (filter().map().sum())
19.12 ms 4.18 GB/s
[C] 手写 C/Rust 8 累加器 SoA
7.32 ms 10.92 GB/s
[D] Rul (.rl) Tier 2 融合 SIMD (0x11)
5.91 ms 13.53 GB/s
[E] Rul (.rl) Tier 2 多核并行 (0x12)
3.19 ms 25.04 GB/s
[F] Rul (.rl) Tier 2 多核 + ZoneMap
1.55 ms 51.53 GB/s
深层流水线验证：BM-HORNER-50（50 步多项式 · 104 个 SSA 节点 · 80 MB）

src/aot.rs 中的线性扫描 YMM 寄存器分配器在 ~20.4 µs 内编译出 3,872 字节的独立 ELF64 程序，耗时 106.58 ms 完成计算——在零 LLVM 依赖下媲美手写 8 累加器 C/Rust (107.96 ms)。

[0x140] 四大第一性原理机制

第一性原理极简，硅片执行数学精确。

传统语言编译缓慢，是因为机器必须阅读人类文本并猜测你的意图。Rul 通过四项直观机制彻底消除了猜测：

01 · 二进制即唯一事实来源 src/bytecode.rs

1. 零文本解析（0% 语法错误）

无需让 AI 拼写数千个容易漏掉分号的字符，AI 直接输出 16 字节二进制积木（或在 ~8.8 µs 内从 .rls 汇编）。处理 1000 万个数字的 7 步流水线在 .rl 中仅占 208 字节，编译出的独立 Linux ELF64 可执行文件仅 817 字节。

1. RulHeader 64 Bytes (64B-aligned)
2. ArenaDescriptor Table arena_count × 16 Bytes
3. ProofEntry Sidecar Table proof_count × 16 Bytes
4. NodeFrame Instruction DAG node_count × 16 Bytes
02 · O(N) 线性内存所有权 src/verifier.rs

2. 版本化内存票据（纳秒级实现 Rust 级安全）

把每个内存池（Arena）想象成一间带有版本号票据（从版本 1 开始）的房间。多条指令可以同时持共享票据读取版本 1（ReadLease 0b01）。一旦某条指令原地修改数据（AffineConsume 0b10），房间立即升至版本 2——后续任何持旧版本 1 票据的指令在 5.78 纳秒内就会被拒之门外，无需缓慢的借用检查器。

TOKEN_OP (32-BIT) = [mode: 2b | arena_id: 14b | version: 16b]
0b01 ReadLease(arena=0, ver=1) ✓ 共享读取（版本号保持为 1）
0b10 AffineConsume(arena=0, ver=1) → 原地修改并升级版本号 = 2
Reuse stale ReadLease(arena=0, ver=1) ✗ 拒绝访问：StaleOrConsumedToken
03 · 零信任沙箱与边界证书 ProofEntry + CapMask

3. 前置边界证书与硬件权限开关

等长数据列在循环内无需任何边界检查即可全速运行（TRIVIAL_BY_SHAPE）。数组切片（ArenaSlice）或索引收集（Gather）必须在加载时出示 16 字节边界证书（ProofEntry）。当硬件权限掩码（CapabilityMask）为 0x0 时，程序在物理层面被禁止访问网络或磁盘。

proof_idx == 0 (90%+ nodes): TRIVIAL_BY_SHAPE (0 runtime checks)
proof_idx > 0 (ArenaSlice / Gather): lo <= hi <= effective_target_len
RulHeader.capability_mask = 0x0: CAP_NONE (Pure Compute Sandbox)
04 · 白盒可审计性 rul trace & decompile

4. X 光级白盒透明（绝非黑盒）

人类无需手写二进制即可掌握 100% 控制权：工程师定义数据结构（ArenaDescriptor）、硬件权限开关（CapabilityMask）与输出契约（AssertContract），AI 在几微秒内重新生成 .rl 文件。随时运行 rul decompile 还原可读文本，或运行 rul trace 查看每一步的最小值、最大值、总和与 NaN=0。

人类定义契约 → AI 微秒级重构 .rl
验证 + 编译总计仅需 ~12 µs
29 操作码完整规范 →
[0x180] 系统对比矩阵与 AGENT MCP

C vs. Go vs. Rust vs. Rul (.rl)

在解析开销、内存安全机制、边界检查、编译延迟与沙箱安全五个维度上的架构对比。

对比维度C (clang -O3)Go (gc)Rust (rustc + LLVM)Rul (.rl) v0.4
主要代码编写者人类程序员人类软件工程团队人类系统工程师AI 智能体（配备人类可审计的白盒工具）
代码载体格式文本 (.c, .h)文本 (.go)文本 (.rs)平坦二进制 .rl（16 字节定长指令）
语法解析开销高中等极高（宏展开、AST）0 ms（直接零拷贝二进制内存映射 mmap）
内存安全机制无（手动指针管理）垃圾回收器 GC（运行时停顿）借用检查器（复杂约束求解）版本化 TokenOp（每节点 O(1) 检查）
数组越界检查不检查（易发缓冲区溢出）每次访问触发运行时分支运行时分支（除非被编译器消除）加载时通过 Shape + ProofEntry 旁路表静态证明
验证与编译耗时数秒亚秒级至数秒数秒至数分钟~5.8 ns/节点验证 + ~6.4 µs ELF64 原生编译
硬件沙箱安全完整操作系统进程权限完整操作系统进程权限完整操作系统进程权限（含 unsafe 库）文件头内嵌 64 位 CapabilityMask 硬件权限掩码
STDIO JSON-RPC 2.0 · src/mcp.rs

内置模型上下文协议服务器 (rul-mcp)

零外部依赖的 stdio JSON-RPC 2.0 服务器，直接向自主 AI 智能体暴露 6 个原生静态验证、差分测试、自动调优与 AOT 编译工具。

GET /.well-known/mcp.json ↗
rul_assemble_and_verify ~8.8 µs + 5.8 ns/node
(rls_source: string) -> VerifiedSummary + .rl hex

将符号 .rls 指令汇编为 128 位二进制 .rl 镜像，并运行单遍 O(N) 静态验证器。

rul_test_differential Tier 0 == Tier 1 == Tier 2
(rls_source: string, arenas: ArenaData[]) -> DiffReport

在 Tier 0 (Oracle)、Tier 1 (Stencil) 与 Tier 2 (L1 Fused) 上同时运行已验证程序，证明按位/ULP 等价性。

rul_autotune_schedule 1-Byte Sweep
(rls_source: string) -> Optimal ScheduleHint + Telemetry

自动扫描 AutoL1Tile (0x10)、SimdStream (0x11) 和 MultiCore (0x12) 策略，选出硬件吞吐量 GB/s 最高的配置。

rul_compile_standalone ~6.4 µs ELF64
(rls_source: string) -> Standalone Linux x86_64 ELF64

使用线性扫描 YMM 寄存器分配器，直接生成零依赖的 Linux x86_64 AVX2 ELF64 可执行文件 (628 B – 1,037 B)。

rul_trace White-Box Inspector
(rls_source: string) -> NodeTraceRow[0..N-1]

返回每个 SSA 指令节点的精确最小值、最大值、总和/真值计数、NaN/Inf 数量以及前 4 个样本值 sample[0..4]。

rul_cas_intrinsics 64-Bit FNV-1a CAS
(op: sort | hash_join | group_by | simd_scan) -> CasHash

在 RulCasStore 中执行已验证的内容寻址 I64/U8 核心算子（sort、hash_join、group_by、simd_scan_byte）。

[0x1C0] 通往 v1.0 路线图

从已验证列式引擎 (v0.4) 迈向通用系统编程语言 (v1.0)

我们在 v0.1–v0.4 阶段特意聚焦于数组与向量流水线（29 个操作码），以便率先在真实硅片上验证 16 字节二进制格式。通过接下来的四个里程碑，Rul 将全面替代 Rust 和 Go：

查看完整技术路线图与工程原则 →
v0.1.0 → v0.4.0 已发布的生产基线
✓ 已投产发布

29 操作码列式 SSA-DAG 核心、白盒追踪器与线性扫描 AVX2 ELF64 AOT 编译器

在真实硬件上验证了 16 字节二进制指令格式、单遍 O(N) 验证器 (~5.8 ns/节点)、三层执行引擎、rul-mcp 服务器以及无需 LLVM 的原生 Linux ELF64 编译器 (~6.4 µs)。

  • [1] 涵盖 29 个操作码的 64 字节 RulHeader、16 字节 ArenaDescriptor、16 字节 ProofEntry 与 16 字节 NodeFrame。
  • [2] 无损双向 .rls <-> .rl 符号汇编器、独立 rul CLI、rul-bench 基准套件与 6 工具 rul-mcp 服务器。
  • [3] 线性扫描 YMM 寄存器分配器 (ymm2..ymm13)，在 80 MB 数组上实现 51.53 GB/s 吞吐量（比 C 快 4.72 倍）。
v0.5 里程碑 1（第 1–2 个月）
● 正在开发

通用控制流、模块化函数与复合数据类型

将 16 字节指令集扩展到数值数组之外，支持通用标量、结构体、枚举、UTF-8 字符串、哈希表、条件分支以及带有终止证明的循环。

  • [1] 原生支持 i64、i32、u8、f32、固定布局结构体、代数标签联合体、已验证 UTF-8 字符串与 Arena 哈希表。
  • [2] SelectBranch：要求两个分支在完全相同的内存版本状态下汇合的条件分支（以 O(1) 复杂度验证）。
  • [3] RegionLoop 与 Call：带 ProofEntry 终止燃料/变体见证的有界循环，以及无需全程序内联即可独立验证的模块化函数。
v0.6 – v0.7 里程碑 2（第 2–3 个月）
○ 计划路线

O(N) 时间内实现 Rust 级堆内存所有权与结构体生命周期

将 32 位 TokenOp 版本票据与 16 字节 ProofEntry 见证从平坦数组推广至基于区域（Region）的堆分配与结构体字段借用。

  • [1] 绑定到线性所有权令牌的确定性区域堆分配与释放，零 GC 停顿且零 malloc/free 碎片。
  • [2] 用于不相交结构体字段并发修改与零拷贝子切片生命周期的 ProofEntry 旁路见证，每条指令以 O(1) 检查。
  • [3] 无需数秒的借用检查器约束求解，即可彻底防止释放后使用 (use-after-free)、双重释放与非法别名。
v0.8 – v0.9 里程碑 3（第 4–5 个月）
○ 计划路线

Go 风格确定性并发与受 CapabilityMask 管控的操作系统 I/O

引入轻量级任务、转移所有权的通道（Channel）以及管控文件、网络与进程系统调用的细粒度文件头权限位。

  • [1] 通过类型化通道发送缓冲区会对发送方令牌执行 AffineConsume 并将所有权转移给接收方——无需 GC 即可在加载时杜绝数据竞争。
  • [2] 扩展 64 位 RulHeader.capability_mask，精细管控文件系统读写、网络套接字、定时器与子进程。
  • [3] 带有 CAP_NONE (0x0) 的 .rl 二进制文件在执行开始前就在数学层面被禁止发起任何网络或磁盘调用。
v1.0 里程碑 4（第 6 个月）
○ 计划路线

多架构原生后端（x86_64、ARM64、WASI）与形式化可靠性证明

无需 LLVM 即可生成跨 Linux、macOS、Windows 和 WebAssembly 的独立可执行文件，并由 Kani 模型检查与 50 个 v1.0 一致性测试套件提供背书。

  • [1] 面向 Linux、macOS 和 Windows 的 x86_64 与 AArch64 (ARM64) 零 LLVM 原生代码生成，以及确定性 WASI 模块。
  • [2] 覆盖二进制解码器、O(N) 验证器与原生代码生成器的 Kani 有界模型检查证明与持续差分模糊测试。
  • [3] 冻结 .rl v1.0 二进制规范并发布公开的 50 程序一致性测试套件。
[0x1F0] 直接技术解答 (AEO / FAQ)

常见问题解答 — 从通俗原理到系统深度

第一性原理通俗解释结合精确的实证测量数据，专为工程师、研究人员与 AI 答案引擎打造。

Q01 什么是 Rul (.rl)？为什么它采用 16 字节二进制格式而不是人类文本？ +
AI 用数字思考，CPU 用二进制运行——但 C、Go 和 Rust 等传统语言却强迫 AI 拼写数千个人类单词，并等待编译器 (rustc/LLVM) 耗费数秒将文本重新翻译回二进制。Rul (.rl) 彻底删除了人类文本中间商：AI 智能体直接输出固定的 16 字节（128 位）二进制积木，自带算法、CPU 调度策略与内存安全票据——将文本解析开销降至 0 ms，并在 ~6.4 µs 内编译出独立的 Linux ELF64 可执行文件。
Q02 Rul 如何在不使用缓慢借用检查器的情况下，以每条指令 ~5.8 ns 的速度验证 Rust 级内存安全？ +
把每个内存缓冲区（Arena）想象成一间带有编号版本票据（从版本 1 开始）的房间。多条指令可以凭共享读取租约 ReadLease (0b01) 同时读取版本 1。当某条指令通过 AffineConsume (0b10) 原地修改缓冲区时，它会检查可变性并将房间升级为版本 2。后续任何仍持有旧版本 1 票据的指令在单次前向扫描（~5.78 ns/节点）中都会以 O(1) 时间在门口被拒绝——无需数秒的借用检查器约束求解。
Q03 如果人类不手写 .rl 二进制文件，工程团队如何调试和维护 Rul 系统？ +
人类无需手写二进制即可保持 100% 控制权——就像医生看 X 光片而无需手绘一样：(1) 人类在前端制定规则——工程师定义数据模式 (ArenaDescriptor)、硬件权限开关 (64 位 CapabilityMask) 与验收契约 (AssertContract)，而 AI 在几微秒内重新生成已验证的 .rl 二进制文件；(2) 通过 `rul decompile` 即时将任意 .rl 文件无损还原为可读的 `.rls` 符号汇编；(3) 通过 `rul trace` 进行 X 光级透视，打印每一步指令的精确最小值、最大值、总和、NaN/Inf 计数以及前 4 个样本值 sample[0..4]。
Q04 如果 Rul 旨在为 AI 智能体替代人类文本语言，为什么 Rul 工具链本身是用 Rust 编写的？ +
每一种全新的系统语言都需要一门初始宿主语言来编写其自举编译器——正如第一个 C 编译器是用汇编写的，第一个 Rust 编译器是用 OCaml 写的一样。我们在 `#![forbid(unsafe_code)]` 约束下使用零外部依赖的纯 Rust 构建了 Rul 验证器、三层执行引擎和原生 ELF64 编译器。一旦安装了独立的 `rul` 二进制文件，用户和 AI 智能体即可直接验证、编译和运行 `.rl` 程序，完全不需要 rustc、Cargo 或 LLVM。
Q05 Rul 是如何仅通过修改一个字节就实现 51.53 GB/s（比手写 C 快 4.72 倍）的？ +
在 Rul 中，硬件调度（第 2 字节：schedule_hint）与算法逻辑（第 0 字节：opcode）完全正交。在 80 MB（10,000,000 个 f64）过滤-平方-求和流水线上，单核 Rul (`0x11 SimdStream`) 将所有操作融合进 AVX2 YMM 寄存器中的 1,024 元素 L1 缓存分块，耗时 5.91 ms，击败耗时 7.32 ms 的手写 8 累加器 C 代码（快 1.24 倍）。将第 2 字节从 0x11 修改为 0x12 (`MultiCore`) 即可将这些 L1 分块并行分发到所有 CPU 核心（3.19 ms，快 2.29 倍）；再启用 `ArenaZoneMap` 块级最小/最大元数据以 O(1) 跳过冷分块，即可在 1.55 ms 内完成（51.53 GB/s，比单核 C 快 4.72 倍，比命令式 AoS 快 45.51 倍）。
Q06 Rul 能否替代 Rust 和 Go 用于通用后端与系统软件开发？ +
可以——这正是 v1.0 四大里程碑路线图的明确目标：里程碑 1 (v0.5) 增加 i64/i32/u8/f32、结构体、标签联合体、UTF-8 字符串、哈希表、O(1) 验证的 SelectBranch 条件分支以及带终止证明的 RegionLoop 循环；里程碑 2 (v0.6–0.7) 将 TokenOp 与 ProofEntry 扩展至基于区域的堆分配与结构体字段借用；里程碑 3 (v0.8–0.9) 引入 Go 风格轻量级任务与所有权转移通道，以及受 CapabilityMask 管控的操作系统调用；里程碑 4 (v1.0) 提供由 Kani 形式化可靠性证明背书的 x86_64、ARM64 与 WASI 零 LLVM 原生后端。