[0x00..0x3F] magic = b"RUL\x00\x01\x00\x00\x00" · 128ビット・バイナリIR
Release v0.4.0 (2026-11-07) ↗

AIエージェントのための 128ビット・バイナリ プログラミング言語。

AIは数値で思考し、CPUはバイナリで動きます。しかしC、Go、RustはAIに人間用のテキストを書かせ、コンパイラが意図を推測するまで何秒も待たせます。Rul (.rl) はこのテキスト仲介者を排除しました。AIはアルゴリズム、CPUスケジュール、メモリ安全チケットを一体化した16バイトのバイナリブロックを直接出力します。結果: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)
ライブ .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)
Artifact (.rl) = Algorithm + Schedule + Proof ✓ 5.78 ns/node
[0x40] 128ビットフレーム
16 Bytes

全命令が固定長バイナリブロック · テキスト構文解析 0 ms

[0x50] 1命令あたり
5.78 ns

メモリ所有権と境界の即時証明(単一パス O(N) 走査)

[0x60] ネイティブコンパイル
6.4 µs

LLVM不要で独立動作するLinux x86_64 ELF64実行ファイルを生成

[0x70] C言語比 4.72倍
51.53 GB/s

1バイトの変更だけで1,000万要素(80 MB)の処理を劇的加速

[0x80] インタラクティブ 128ビット・ワークベンチ

1つの16バイト命令 = アルゴリズム + スケジュール + 安全証明

任意の命令ノード (#0..#6) またはバイト (0..15) を選択して、8ビットレジスタ内訳、O(N) 検証ルール、ホワイトボックストレースを確認できます。

アルゴリズム・レーン(何を計算するか:Opcode / 被演算子) スケジュール・レーン(どう実行するか: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) に変更しても安全性証明を変えずにCPU実行を並列化します。

ノード #3: 中間ヒープ割り当てゼロでL1キャッシュレジスタ内で融合実行される要素ごとの8レーンベクトル二乗 ($n0 * $n0)。
シンボリック・アセンブリ表示 (src/main.rls — .rl 内で 208 B) ~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バイト・ハードウェアスケジュール変異

わずか1バイト(Byte 2)の変異で、手書きC言語を4.72倍凌駕。

実ワークロード:1,000万個の浮動小数点数(80 MB配列)から > 1000.0 を抽出し、2乗して合計。下のByte 2 (schedule_hint) を切り替えると、アルゴリズムは100%同一のまま実行時間が5.91 msから1.55 msへ短縮されます:

選択中の BYTE 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) を組み合わせ、条件外のタイルをDRAM読み取りなしで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レジスタアロケータは、3,872バイトの単体ELF64バイナリを約20.4 µsでコンパイルし、106.58 msで実行します。LLVMなしで手書き8アキュムレータC/Rust (107.96 ms) に匹敵します。

[0x140] 第一原理に基づく4つのコア機構

第一原理はシンプルに。シリコン上では数学的厳密さを。

従来の言語は、機械が人間の文字を読んで意図を推測するためコンパイルに時間がかかります。Rulは4つの自明なメカニズムで推測を完全に排除します:

01 · バイナリこそ唯一の情報源 src/bytecode.rs

1. テキスト構文解析ゼロ(構文エラー 0%)

セミコロンの抜けやすい何千文字ものテキストをAIに書かせる代わりに、16バイトのバイナリブロックを直接出力します(または約8.8 µsで .rls からアセンブル)。1,000万個の数値を処理する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 nsで入り口で拒否されます。

TOKEN_OP (32-BIT) = [mode: 2b | arena_id: 14b | version: 16b]
0b01 ReadLease(arena=0, ver=1) ✓ 共有読み取り(ver = 1 を維持)
0b10 AffineConsume(arena=0, ver=1) → インプレース更新& ver = 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線ホワイトボックス透明性(ブラックボックス化しない)

人間がバイナリを手打ちする必要はありません。エンジニアがデータ構造(ArenaDescriptor)、ハードウェア権限(CapabilityMask)、出力契約(AssertContract)を設定すれば、AIが数マイクロ秒で .rl を再生成します。いつでも rul decompile で可読テキストに戻し、rul trace で各ステップの正確な min、max、sum、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)
メモリ安全性なし(手動ポインタ管理)ガベージコレクタ(実行時一時停止)借用チェッカー(制約ソルバー)バージョン付き TokenOp(ノード毎 O(1) 検査)
配列境界チェックなし(バッファオーバーフローの危険)アクセス毎の実行時分岐実行時分岐(最適化で除去されない限り)ロード時に Shape + ProofEntry 表で静的証明
検証+コンパイル時間数秒サブ秒〜数秒数秒〜数分約5.8 ns/ノード検証 + 約6.4 µs ELF64 AOT
サンドボックス安全性OSプロセスの全権限OSプロセスの全権限OSプロセスの全権限(unsafeクレート)ファイルヘッダ内の64ビット CapabilityMask
STDIO JSON-RPC 2.0 · src/mcp.rs

組み込み Model Context Protocol サーバー (rul-mcp)

外部依存ゼロの stdio JSON-RPC 2.0 サーバー。検証、差分テスト、自動チューニング、AOTコンパイルの6つのネイティブツールをAIエージェントに直接提供します。

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命令ノードの正確な min、max、sum/trues、NaN/Inf カウント、および先頭サンプル 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では、まず実機のシリコン上で16バイト・バイナリ形式を実証するため、配列・ベクトル処理(29オペコード)に限定しました。4つのマイルストーンを経て、AI生成システムソフトウェア向けにRustとGoを置き換えます:

技術ロードマップと設計原則の全文を見る →
v0.1.0 → v0.4.0 出荷済み本番ベースライン
✓ 本番稼働中

29オペコード列指向SSA-DAGコア、ホワイトボックストレーサー&線形スキャンAVX2 ELF64 AOT

実機ハードウェア上で16バイトバイナリ命令形式、単一パスO(N)検証器(約5.8 ns/ノード)、3層実行エンジン、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] 80 MB配列で 51.53 GB/s(C言語の4.72倍)を達成する線形スキャンYMMレジスタアロケータ (ymm2..ymm13)。
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証人を、フラット配列からリージョンベースのヒープ割り当てと構造体フィールド借用へと一般化します。

  • [1] 線形所有権トークンに紐づく決定論的リージョンヒープ割り当てと解放。GCポーズもmalloc/free断片化もゼロ。
  • [2] 互いに素な構造体フィールドの更新とゼロコピー部分スライスのライフタイムを1命令あたりO(1)で検証するProofEntry証人。
  • [3] 何秒もかかる借用チェッカーの制約解決なしで、use-after-free、二重解放、エイリアシングを完全に防止。
v0.8 – v0.9 マイルストーン 3(4〜5ヶ月目)
○ 計画済み

Goスタイルの決定論的並行処理と CapabilityMask 制御OS I/O

軽量タスク、所有権を転送するチャネル、ファイル・ネットワーク・プロセスのシステムコールを制御する細粒度ヘッダ権限ビットを導入します。

  • [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エージェントはアルゴリズム、CPUスケジュール、メモリ安全チケットを一体化した固定長16バイト(128ビット)のバイナリブロックを直接出力するため、構文解析は 0 ms になり、約6.4 µsで独立したLinux ELF64実行ファイルをコンパイルできます。
Q02 Rul はどうやって遅い借用チェッカーなしに1命令約5.8 nsでRust級のメモリ安全性を検証するのですか? +
各メモリバッファ(Arena)をバージョン1から始まる番号付きチケットのある部屋だと考えてください。複数の命令が共有チケット ReadLease (0b01) を使って同時にバージョン1を読み取れます。命令が AffineConsume (0b10) でバッファをその場で変更すると、可変性を確認して部屋をバージョン2に進めます。古いバージョン1のチケットを持った後続の命令は、単一の順方向パス(約5.78 ns/ノード)の中で入り口でO(1)時間で拒否されます。何秒もかかる借用チェッカーのソルバーは不要です。
Q03 人間が .rl バイナリを手書きしない場合、開発チームはどうやってデバッグや保守を行うのですか? +
医師がレントゲン写真を自分で手描きしなくても診断できるように、人間はバイナリを手打ちせずに100%の制御を維持できます:(1) 人間が入り口でルールを設定 — エンジニアがデータスキーマ (ArenaDescriptor)、ハードウェア権限スイッチ (64ビット CapabilityMask)、受け入れ検査 (AssertContract) を定義し、AIが数マイクロ秒で検証済み .rl バイナリを再生成します。(2) `rul decompile` で任意の .rl ファイルを即座に可読な `.rls` アセンブリに変換できます。(3) `rul trace` でX線検査のように各命令ステップの正確な min、max、sum、NaN/Inf 数、サンプル値 sample[0..4] を出力できます。
Q04 Rul がAI向けにテキスト言語を置き換えるためのものなら、なぜツールチェーン自体はRustで書かれているのですか? +
すべての新しいシステム言語には、最初のブートストラップ・コンパイラを書くためのホスト言語が必要です(最初のCコンパイラがアセンブリで書かれ、最初のRustコンパイラがOCamlで書かれたのと同じです)。私たちは `#![forbid(unsafe_code)]` のもと、外部依存ゼロのRustでRul検証器、3層実行エンジン、ネイティブELF64コンパイラを構築しました。単体の `rul` バイナリをインストールすれば、ユーザーやAIエージェントは rustc、Cargo、LLVM を一切必要とせずに直接 `.rl` プログラムを検証・コンパイル・実行できます。
Q05 Rul はどうやってたった1バイトを変更するだけで 51.53 GB/s(手書きCの4.72倍)を達成するのですか? +
Rulでは、ハードウェアスケジューリング(Byte 2: schedule_hint)がアルゴリズム論理(Byte 0: opcode)と完全に分離(直交)しています。80 MB(1,000万個の f64)のフィルタ・二乗・合計パイプラインにおいて、単一コアの Rul (`0x11 SimdStream`) は全演算をAVX2 YMMレジスタ内の1,024要素L1キャッシュタイルに融合し、手書き8アキュムレータCの 7.32 ms に対して 5.91 ms(1.24倍高速)で実行します。Byte 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 を置き換えることができますか? +
はい — それこそが4マイルストーンからなる 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 によるOSシステムコール制御を導入。マイルストーン4 (v1.0) で Kani 形式証明に裏付けられた x86_64、ARM64、WASI 向けゼロLLVMネイティブバックエンドを提供します。