[0x00..0x3F] magic = b"RUL\x00\x01\x00\x00\x00" · Nhị Phân 128-Bit IR

Ngôn Ngữ Lập Trình Nhị Phân 128-Bit Dành Cho AI Agents.

AI suy nghĩ bằng con số và CPU chạy bằng nhị phân — nhưng C, Go, Rust lại bắt AI phải gõ chữ viết của con người rồi chờ hàng giây để trình biên dịch đoán ý. Rul (.rl) xóa bỏ khâu trung gian văn bản đó: AI phát trực tiếp các viên gạch nhị phân 16-byte gắn sẵn Thuật toán, Lịch trình CPU và Vé an toàn bộ nhớ ngay từ đầu. Kết quả: kiểm chứng an toàn trong 5.8 ns, đóng gói file chạy độc lập trong 6.4 µs và chạy nhanh hơn C viết tay 4.72 lần.

NGUYÊN LÝ ĐẦU TIÊN TRONG 10 GIÂY · XÓA BỎ TRUNG GIAN VĂN BẢN

✗ CÁCH CŨ (C / Go / Rust) AI Nghĩ (Con số) → Gõ Chữ Con Người → Trình Biên Dịch Đọc Chữ & Đoán Ý (Mất Hàng Giây) → Mã Máy (0/1)

✓ NGUYÊN LÝ RUL (.rl) AI Nghĩ (Con số) → Phát Thẳng Gạch Nhị Phân 16-Byte (5.8 ns Kiểm Chứng + 6.4 µs Biên Dịch) → Chạy Nhanh Hơn C 4.72x

Gạch Nhị Phân 16-Byte (0ms Đọc Chữ) + 6.4 µs Biên Dịch ELF64 (Không LLVM) + 5.8 ns Vé An Toàn (Quét 1 Lượt 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)

Mổ Xẻ Khung Lệnh 16-Byte ↓ Đọc Đặc Tả v0.4 Whitepaper (DOI) ↗

ẢNH NHỊ PHÂN .RL TRỰC TIẾP · 7 NODE SSA = 208 BYTES -> 817-BYTE ELF64 CAP_NONE=0x0

Nhấp vào bất kỳ khung lệnh 16-byte nào bên dưới để giải mã từng bit, bằng chứng an toàn và kết quả thực thi:

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 · read(0,1) · a=0 b=0

#1 ConstF64

02 11 11 00 · pure · const=100.0

#2 CmpGt

14 38 11 00 · pure · a=$n0 b=$n1

#3 Mul

12 18 12 00 · pure · a=$n0 b=$n0

#4 SelectZero

15 18 11 00 · pure · a=$n2 b=$n3

#5 ReduceSum

21 11 11 00 · pure · a=$n4 b=0

#6 AssertContract

40 11 11 00 · pure · a=$n5 b=0

Artifact (.rl) = Algorithm + Schedule + Proof ✓ 5.78 ns/node

[0x40] Khung 128-Bit

16 Bytes

Mỗi Lệnh Là 1 Viên Gạch Nhị Phân Cố Định · 0 ms Đọc Chữ

[0x50] mỗi lệnh

5.78 ns

Kiểm Chứng An Toàn Bộ Nhớ & Biên Tức Thì (Quét 1 Lượt O(N))

[0x60] biên dịch mã máy

6.4 µs

Đóng Gói Thẳng File Thực Thi Linux x86_64 ELF64 Không Cần LLVM

[0x70] 4.72x so với C

51.53 GB/s

Xử Lý 10 Triệu Số (80 MB) Tăng Tốc Nhờ Đổi Đúng 1 Byte

[0x80] BÀN THỬ NGHIỆM NHỊ PHÂN 128-BIT

ALIGN=64B · FRAME=16B (128-BIT)

Một Khung Lệnh 16-Byte = Thuật Toán + Lịch Trình + Bằng Chứng

Chọn bất kỳ lệnh nào (#0..#6) hoặc nhấp vào từng byte (0..15) để xem thanh ghi 8-bit, quy tắc kiểm chứng O(N) và kết quả chụp cắt lớp hộp trắng.

Làn Thuật Toán (Làm gì: Opcode / Toán hạng) Làn Lịch Trình (Chạy thế nào: SIMD / Đa nhân) Làn Bằng Chứng (An toàn: Vé phiên bản / Biên)

NODE #3 ($n3) node $n3 = Mul f64x8 fg=1 pol=simd proof=0 tok=pure a=$n0 b=$n0

16 BYTES = 128 BITS

GIẢI MÃ THANH GHI 8-BIT · 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

Trường: schedule_hint Kiểu: u8

✓ Quy Tắc Kiểm Chứng O(N) Ngay Lúc Nạp File (~5.78 ns) (fusion_group << 4) | exec_policy

Byte lịch trình phần cứng độc lập: đổi 0x11 (SimdStream) -> 0x12 (MultiCore) giúp tăng tốc đa nhân mà không làm đổi bằng chứng an toàn.

Node #3: Nhân bình phương từng phần tử 8 làn vector ($n0 * $n0) hợp nhất ngay trong thanh ghi L1, không cấp phát bộ nhớ trung gian.

Mã Ký Hiệu Cho Con Người Đọc (src/main.rls — 208 B trong .rl) ~8.8 µs assemble

cap 0x0

arena 0 len=4096 lane=f64x8 mut=false align=64 ver=1

output $n6

Bảng Chụp X-Quang Từng Bước (rul trace — 7 Node SSA) Nhấp vào bất kỳ dòng nào để đồng bộ khung nhị phân 16-byte và mã ký hiệu

NODE	OPCODE	KIND	LEN	MIN	MAX	SUM/TRUES	SAMPLE[0..4]
#0	ArenaInput	ColumnF64	4096	0.5000	249.5000	504608.0000	[0.500, 1.500, 2.500, 3.500]
#1	ConstF64	Scalar	1	100.0000	100.0000	100.0000	[100.000]
#2	CmpGt	ColumnMask	4096	0.0000	1.0000	2400.0000	[0.000, 0.000, 0.000, 0.000]
#3	Mul	ColumnF64	4096	0.2500	62250.2500	83627904.0000	[0.250, 2.250, 6.250, 12.250]
#4	SelectZero	ColumnF64	4096	0.0000	62250.2500	77999800.0000	[0.000, 0.000, 0.000, 0.000]
#5	ReduceSum	Scalar	1	77999800.0000	77999800.0000	77999800.0000	[77999800.000]
#6	AssertContract	Scalar	1	77999800.0000	77999800.0000	77999800.0000	[77999800.000]

[0x100] ĐỘT BIẾN LỊCH TRÌNH 1-BYTE

ALIGN=64B · FRAME=16B (128-BIT)

Đổi Đúng 1 Byte (Byte 2). Vượt Qua C Viết Tay 4.72 Lần.

Bài toán thực tế: 10.000.000 số thực (mảng 80 MB) — lọc các số > 1000.0, bình phương rồi cộng dồn. Hãy bấm thử đổi Byte 2 (schedule_hint) bên dưới: thuật toán giữ nguyên 100%, nhưng thời gian chạy giảm từ 5.91 ms xuống chỉ còn 1.55 ms:

BYTE 2 ĐANG CHỌN (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: Kết hợp đa nhân L1 với siêu dữ liệu min/max từng khối (ArenaZoneMap) để bỏ qua các khối không thỏa điều kiện lọc trong O(1).

[A] AoS Truyền thống + Vec::collect() 1 Nhân AoS + Cấp phát Heap

70.66 ms 1.13 GB/s 0.10x

[B] Rust SoA Chuẩn (filter().map().sum()) 1 Nhân Chuỗi Iterator SoA

19.12 ms 4.18 GB/s 0.38x

[C] C/Rust Viết Tay 8-Accumulator SoA 1 Nhân 8 Làn Trải Vòng Lặp (Mốc chuẩn)

7.32 ms 10.92 GB/s 1.00x (Baseline)

[D] Rul (.rl) Tier 2 SIMD Hợp Nhất (0x11) 1 Nhân L1-Tile SIMD (SimdStream)

5.91 ms 13.53 GB/s 1.24x (1-Core vs 1-Core)

[E] Rul (.rl) Tier 2 Đa Nhân (0x12) Toàn Bộ Nhân (Đổi 1 Byte Lịch Trình)

3.19 ms 25.04 GB/s 2.29x (Schedule Byte)

[F] Rul (.rl) Tier 2 Đa Nhân + ZoneMap Toàn Bộ Nhân + Bỏ Qua Khối Lạnh O(1)

1.55 ms 51.53 GB/s 4.72x (Peak Speedup)

Kiểm Chứng Pipeline Sâu: BM-HORNER-50 (Đa Thức 50 Bước · 104 Node SSA · 80 MB)

Bộ cấp phát thanh ghi YMM quét tuyến tính trong src/aot.rs biên dịch file ELF64 độc lập 3.872 byte chỉ trong ~20.4 µs và chạy mất 106.58 ms — ngang ngửa C/Rust 8-accumulator viết tay (107.96 ms) mà không cần LLVM.

[0x140] BỐN CƠ CHẾ NGUYÊN LÝ ĐẦU TIÊN

ALIGN=64B · FRAME=16B (128-BIT)

Đơn Giản Ở Nguyên Lý Gốc. Chính Xác Tuyệt Đối Trên Phần Cứng.

Các ngôn ngữ truyền thống biên dịch chậm vì máy tính phải đọc văn bản của con người rồi đoán ý định. Rul loại bỏ hoàn toàn việc đoán mò bằng 4 cơ chế hiển nhiên:

01 · NHỊ PHÂN LÀ NGUỒN CHÂN LÝ DUY NHẤT src/bytecode.rs

1. Không Đọc Chữ, Không Lỗi Cú Pháp (0% Syntax Errors)

Thay vì bắt AI gõ hàng nghìn ký tự dễ thiếu dấu chấm phẩy, AI phát trực tiếp các viên gạch nhị phân 16-byte (hoặc lắp ráp từ file .rls trong ~8.8 µs). Một chương trình 7 bước xử lý 10 triệu con số chỉ nặng đúng 208 byte ở dạng .rl và đóng gói thành file chạy Linux ELF64 độc lập chỉ 817 byte.

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 · QUYỀN SỞ HỮU TUYẾN TÍNH O(N) src/verifier.rs

2. Vé Bộ Nhớ Đánh Số Phiên Bản (An Toàn Như Rust Trong Nano-Giây)

Hãy hình dung mỗi vùng nhớ (Arena) như một căn phòng có vé đánh số bắt đầu từ bản số 1. Nhiều lệnh có thể cùng đọc bản số 1 (ReadLease 0b01). Ngay khi có một lệnh sửa dữ liệu tại chỗ (AffineConsume 0b10), căn phòng đổi sang bản số 2 — mọi lệnh phía sau cầm vé bản số 1 cũ sẽ bị chặn ngay ở cửa chỉ trong 5.78 ns mà không cần Borrow Checker chậm chạp.

TOKEN_OP (32-BIT) = [mode: 2b | arena_id: 14b | version: 16b]

0b01 ReadLease(arena=0, ver=1) ✓ Đọc Chung (giữ nguyên ver = 1)

0b10 AffineConsume(arena=0, ver=1) → Ghi Đè & Tăng ver = 2

Reuse stale ReadLease(arena=0, ver=1) ✗ Từ Chối: StaleOrConsumedToken

03 · SANDBOX KHÔNG TIN CẬY & CHỨNG CHỈ BIÊN ProofEntry + CapMask

3. Chứng Chỉ Biên Ngay Từ Đầu & Công Tắc Quyền Phần Cứng

Các cột dữ liệu cùng chiều dài được chạy thẳng không cần kiểm tra tràn mảng trong vòng lặp (TRIVIAL_BY_SHAPE). Khi cần cắt mảng (ArenaSlice) hoặc nhảy chỉ số (Gather), lệnh bắt buộc nộp kèm chứng chỉ biên 16-byte (ProofEntry) ngay lúc nạp file. Và khi công tắc quyền phần cứng (CapabilityMask) bằng 0x0, file thực thi bị khóa vật lý không thể chạm vào mạng hay ổ cứng.

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 · KIỂM TOÁN HỘP TRẮNG rul trace & decompile

4. Chụp Cắt Lớp Hộp Trắng (Không Bao Giờ Là Hộp Đen)

Con người không cần tự gõ nhị phân mà vẫn nắm quyền kiểm soát 100%: kỹ sư đặt khung dữ liệu (ArenaDescriptor), công tắc quyền (CapabilityMask) và hợp đồng đầu ra (AssertContract); AI đúc lại file .rl trong vài micro-giây. Bất cứ lúc nào, chỉ cần gõ rul decompile để đọc lại dạng chữ hoặc rul trace để soi rõ min, max, sum và NaN=0 ở từng bước.

Hợp Đồng Con Người → AI Tái Tạo .rl

Kiểm Chứng + Biên Dịch trong ~12 µs

Đặc Tả 29 Opcode →

[0x180] MA TRẬN HỆ THỐNG & AGENT MCP

ALIGN=64B · FRAME=16B (128-BIT)

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

So sánh trực diện về chi phí phân tích cú pháp, cơ chế an toàn bộ nhớ, kiểm tra biên mảng, thời gian biên dịch và bảo mật sandbox.

TIÊU CHÍ	C (clang -O3)	Go (gc)	Rust (rustc + LLVM)	Rul (.rl) v0.4
Chủ thể viết mã chính	Lập trình viên con người	Đội ngũ kỹ sư phần mềm	Kỹ sư lập trình hệ thống	AI Agents (kèm công cụ kiểm toán hộp trắng cho người)
Định dạng mã nguồn	Văn bản (.c, .h)	Văn bản (.go)	Văn bản (.rs)	Nhị phân phẳng .rl (Khung lệnh 16-Byte)
Chi phí phân tích cú pháp	Cao	Trung bình	Rất cao (Macros, AST)	0 ms (Nạp nhị phân trực tiếp zero-copy)
An toàn bộ nhớ	Không (Quản lý con trỏ thủ công)	Bộ thu gom rác GC (Dừng ngắt quãng)	Borrow Checker (Giải hệ ràng buộc)	TokenOp có phiên bản (Kiểm tra O(1) mỗi node)
Kiểm tra tràn biên mảng	Không kiểm tra (Dễ tràn bộ đệm)	Rẽ nhánh kiểm tra lúc chạy	Rẽ nhánh lúc chạy (trừ khi tối ưu)	Kiểm chứng lúc nạp qua Shape + bảng ProofEntry
Thời gian Kiểm chứng + Biên dịch	Hàng giây	Nửa giây đến vài giây	Hàng giây đến hàng phút	~5.8 ns/node Kiểm chứng + ~6.4 µs ELF64 AOT
Bảo mật Sandbox phần cứng	Toàn quyền tiến trình OS	Toàn quyền tiến trình OS	Toàn quyền tiến trình OS (unsafe crates)	Bitmask CapabilityMask 64-Bit ngay ở Header

STDIO JSON-RPC 2.0 · src/mcp.rs

Máy Chủ Model Context Protocol Tích Hợp Sẵn (rul-mcp)

Máy chủ stdio JSON-RPC 2.0 không phụ thuộc ngoài, cung cấp 6 công cụ gốc giúp AI Agents tự động lắp ráp, kiểm chứng, chạy đối chiếu 3 tầng, tối ưu lịch trình và biên dịch ELF64.

GET /.well-known/mcp.json ↗

rul_assemble_and_verify ~8.8 µs + 5.8 ns/node

(rls_source: string) -> VerifiedSummary + .rl hex

Lắp ráp mã ký hiệu .rls thành ảnh nhị phân .rl 128-bit và chạy bộ kiểm chứng tĩnh 1 lượt O(N).

rul_test_differential Tier 0 == Tier 1 == Tier 2

(rls_source: string, arenas: ArenaData[]) -> DiffReport

Chạy đối chiếu chương trình trên cả Tier 0 (Oracle), Tier 1 (Stencil) và Tier 2 (L1 Fused) để chứng minh kết quả khớp tuyệt đối.

rul_autotune_schedule 1-Byte Sweep

(rls_source: string) -> Optimal ScheduleHint + Telemetry

Quét qua các chính sách AutoL1Tile (0x10), SimdStream (0x11), MultiCore (0x12) và giữ lại cấu hình đạt băng thông GB/s cao nhất.

rul_compile_standalone ~6.4 µs ELF64

(rls_source: string) -> Standalone Linux x86_64 ELF64

Phát sinh file thực thi Linux x86_64 AVX2 ELF64 độc lập (628 B – 1.037 B) với bộ cấp phát thanh ghi YMM quét tuyến tính.

rul_trace White-Box Inspector

(rls_source: string) -> NodeTraceRow[0..N-1]

Trả về bảng thống kê min, max, sum/trues, số lượng NaN/Inf và 4 mẫu đầu tiên tại từng node SSA để con người và AI kiểm tra.

rul_cas_intrinsics 64-Bit FNV-1a CAS

(op: sort | hash_join | group_by | simd_scan) -> CasHash

Thực thi các hạt nhân I64/U8 định danh theo nội dung (sort, hash_join, group_by, simd_scan_byte) trong RulCasStore.

[0x1C0] LỘ TRÌNH ĐẾN v1.0

ALIGN=64B · FRAME=16B (128-BIT)

Từ Engine Dữ Liệu Cột (v0.4) Đến Ngôn Ngữ Hệ Thống Đa Dụng (v1.0)

Chúng tôi chủ đích giới hạn v0.1–v0.4 ở bài toán mảng và vector (29 opcode) để chứng minh khung nhị phân 16-byte chạy thật trên phần cứng trước. Qua 4 cột mốc tiếp theo, Rul mở rộng để thay thế Rust và Go cho phần mềm hệ thống do AI viết:

Xem Chi Tiết Lộ Trình Kỹ Thuật & Nguyên Tắc →

v0.1.0 → v0.4.0 Đã Phát Hành (Nền Tảng Sản Xuất)

✓ ĐÃ PHÁT HÀNH

Lõi SSA-DAG Dữ Liệu Cột 29 Opcode, White-Box Tracer & Trình Biên Dịch AVX2 ELF64 AOT

Chứng minh thực nghiệm khung lệnh nhị phân 16-byte, bộ kiểm chứng O(N) 1 lượt (~5.8 ns/node), engine 3 tầng, máy chủ rul-mcp và trình biên dịch mã máy Linux ELF64 không cần LLVM (~6.4 µs).

[1] RulHeader 64-byte, ArenaDescriptor 16-byte, ProofEntry 16-byte và NodeFrame 16-byte với 29 opcode.
[2] Bộ dịch hai chiều không suy hao .rls <-> .rl, công cụ dòng lệnh rul, rul-bench và máy chủ rul-mcp 6 công cụ.
[3] Bộ cấp phát thanh ghi YMM quét tuyến tính (ymm2..ymm13) đạt băng thông 51.53 GB/s (nhanh hơn C 4.72 lần).

v0.5 Cột Mốc 1 (Tháng 1–2)

● ĐANG TRIỂN KHAI

Luồng Điều Khiển Đa Dụng, Hàm Mô-đun & Kiểu Dữ Liệu Phức Hợp

Mở rộng tập lệnh 16-byte vượt khỏi mảng số học để hỗ trợ số nguyên, struct, enum, chuỗi UTF-8, bảng băm, rẽ nhánh và vòng lặp có chứng chỉ dừng.

[1] Hỗ trợ trực tiếp i64, i32, u8, f32, struct cố định, enum đại số, chuỗi UTF-8 hợp lệ và bảng băm trên Arena.
[2] SelectBranch: rẽ nhánh điều kiện bắt buộc hai nhánh hội tụ về cùng trạng thái phiên bản bộ nhớ (kiểm tra trong O(1)).
[3] RegionLoop & Call: vòng lặp kèm chứng chỉ dừng trong ProofEntry và bảng hàm mô-đun kiểm chứng độc lập không cần inline toàn chương trình.

v0.6 – v0.7 Cột Mốc 2 (Tháng 2–3)

○ THEO LỘ TRÌNH

Quyền Sở Hữu Heap & Vòng Đời Struct Cỡ Rust Trong Thời Gian O(N)

Tổng quát hóa token phiên bản 32-bit TokenOp và bảng ProofEntry 16-byte từ mảng phẳng sang cấp phát vùng nhớ Heap (Region) và mượn trường struct.

[1] Cấp phát và giải phóng vùng nhớ Heap tất định gắn liền với token sở hữu tuyến tính, không cần GC và không phân mảnh malloc/free.
[2] Chứng chỉ ProofEntry cho phép ghi đồng thời các trường struct tách biệt và kiểm tra vòng đời lát cắt zero-copy trong O(1).
[3] Chống tuyệt đối lỗi use-after-free, double-free và aliasing mà không tốn hàng giây giải hệ phương trình như Borrow Checker của rustc.

v0.8 – v0.9 Cột Mốc 3 (Tháng 4–5)

○ THEO LỘ TRÌNH

Đồng Thời Định Tính Kiểu Go & Hệ Thống I/O Kiểm Soát Bằng CapabilityMask

Bổ sung tác vụ nhẹ (tasks), kênh truyền chuyển giao quyền sở hữu (channels) và mặt nạ quyền hạn phần cứng chi tiết cho syscall tệp, mạng và tiến trình.

[1] Gửi bộ đệm qua channel sẽ tiêu thụ token của bên gửi (AffineConsume) và chuyển quyền sở hữu sang bên nhận — triệt tiêu data race ngay lúc nạp mà không cần GC.
[2] Mở rộng RulHeader.capability_mask 64-bit để kiểm soát đọc/ghi file, socket mạng, bộ đếm thời gian và tiến trình con.
[3] File .rl có CAP_NONE (0x0) bị khóa chặt về mặt toán học khỏi mọi lời gọi mạng hoặc ổ cứng trước khi chương trình kịp chạy.

v1.0 Cột Mốc 4 (Tháng 6)

○ THEO LỘ TRÌNH

Trình Biên Dịch Mã Máy Đa Kiến Trúc (x86_64, ARM64, WASI) & Chứng Minh Hình Thức Kani

Phát sinh file thực thi độc lập trên Linux, macOS, Windows và WebAssembly không cần LLVM, được bảo chứng bởi kiểm chứng mô hình Kani và bộ 50 bài test chuẩn v1.0.

[1] Sinh mã máy trực tiếp không cần LLVM cho x86_64 và AArch64 (ARM64) trên Linux, macOS, Windows cùng mô-đun WebAssembly (WASI).
[2] Chứng minh tính đúng đắn bằng Kani model-checking và kiểm thử đối chiếu liên tục (differential fuzzing) trên toàn bộ trình giải mã, verifier và AOT.
[3] Đóng băng đặc tả nhị phân .rl v1.0 và công bố bộ 50 chương trình kiểm chuẩn chính thức.

[0x1F0] GIẢI ĐÁP KỸ THUẬT TRỰC TIẾP (AEO / FAQ)

ALIGN=64B · FRAME=16B (128-BIT)

Câu Hỏi Thường Gặp — Từ Dễ Hiểu Đến Chuyên Sâu

Giải thích từ nguyên lý gốc kết hợp số liệu thực nghiệm chính xác cho kỹ sư, nhà nghiên cứu và các công cụ tìm kiếm AI.

Q01 Rul (.rl) là gì và vì sao nó dùng khung nhị phân 16-byte thay vì chữ viết của con người? +

AI suy nghĩ bằng con số và chip CPU chạy bằng nhị phân — nhưng các ngôn ngữ cũ như C, Go, Rust lại bắt AI phải gõ hàng nghìn chữ cái của con người rồi chờ trình biên dịch (rustc/LLVM) tốn hàng giây dịch ngược lại thành nhị phân. Rul (.rl) xóa bỏ hoàn toàn khâu trung gian văn bản đó: AI đúc thẳng các viên gạch nhị phân 16-byte (128-bit) gắn sẵn Thuật toán, Lịch trình CPU và Vé an toàn bộ nhớ — loại bỏ 100% thời gian đọc chữ (0 ms) và đóng gói ra file thực thi Linux ELF64 độc lập chỉ trong ~6.4 µs.

Q02 Làm thế nào Rul kiểm tra an toàn bộ nhớ cỡ Rust chỉ trong ~5.8 ns mỗi lệnh mà không cần Borrow Checker chậm chạp? +

Hãy hình dung mỗi vùng nhớ (Arena) như một căn phòng có vé đánh số phiên bản bắt đầu từ bản số 1. Nhiều lệnh có thể cùng đọc bản số 1 qua vé đọc chung ReadLease (0b01). Ngay khi có một lệnh sửa dữ liệu tại chỗ bằng AffineConsume (0b10), nó kiểm tra quyền sửa và nâng căn phòng lên bản số 2. Mọi lệnh phía sau còn cầm vé bản số 1 cũ sẽ bị chặn ngay ở cửa chỉ trong một lượt quét duy nhất (~5.78 ns/lệnh) — đạt độ an toàn của Rust mà không tốn hàng giây giải phương trình như Borrow Checker.

Q03 Nếu con người không tự gõ mã nhị phân .rl, đội ngũ kỹ sư kiểm soát, debug và bảo trì hệ thống Rul bằng cách nào? +

Con người nắm 100% quyền kiểm soát mà không cần tự gõ nhị phân — giống như bác sĩ đọc phim X-quang mà không cần tự vẽ bằng tay: (1) Con người đặt luật ở đầu vào — kỹ sư thiết lập khung dữ liệu (ArenaDescriptor), công tắc quyền phần cứng (CapabilityMask 64-bit) và điều kiện nghiệm thu (AssertContract), còn AI đúc lại file .rl chỉ trong vài micro-giây; (2) Xem lại dạng chữ tức thì qua lệnh `rul decompile` chuyển file .rl sang mã .rls dễ đọc; (3) Chụp X-quang từng bước qua lệnh `rul trace` in rõ giá trị nhỏ nhất, lớn nhất, tổng, số lỗi NaN/Inf và 4 phần tử mẫu tại mọi bước lệnh.

Q04 Tại sao bộ công cụ Rul lại được viết bằng Rust nếu Rul sinh ra để thay thế các ngôn ngữ văn bản cho AI? +

Mọi ngôn ngữ hệ thống mới đều cần một ngôn ngữ máy chủ ban đầu để viết trình biên dịch khởi thủy — giống như trình biên dịch C đầu tiên được viết bằng hợp ngữ và trình biên dịch Rust đầu tiên được viết bằng OCaml. Chúng tôi xây dựng bộ kiểm chứng, engine thực thi 3 tầng và trình biên dịch ELF64 của Rul bằng Rust thuần không phụ thuộc ngoài với chốt chặn #![forbid(unsafe_code)]. Khi đã cài file thực thi độc lập `rul`, người dùng và AI biên dịch và chạy thẳng các chương trình .rl mà không cần đến rustc, Cargo hay LLVM.

Q05 Làm sao Rul đạt tốc độ 51.53 GB/s (nhanh hơn C viết tay 4.72 lần) chỉ bằng cách đổi đúng 1 byte? +

Trong Rul, lịch trình phần cứng (Byte 2: schedule_hint) tách biệt hoàn toàn với thuật toán (Byte 0: opcode). Trên bài toán lọc-bình phương-cộng dồn mảng 80 MB (10 triệu số f64), Rul đơn nhân (`0x11 SimdStream`) hợp nhất toàn bộ phép toán vào các khối đệm L1 1.024 phần tử trên thanh ghi AVX2 YMM, hoàn thành trong 5.91 ms so với 7.32 ms của C 8-accumulator viết tay (nhanh hơn 1.24x). Chỉ cần đổi Byte 2 từ 0x11 sang 0x12 (`MultiCore`), các khối L1 được chạy song song trên toàn bộ nhân CPU (3.19 ms, nhanh hơn 2.29x); khi bật thêm siêu dữ liệu `ArenaZoneMap`, các khối không thỏa điều kiện lọc được bỏ qua trong O(1), rút thời gian xuống còn 1.55 ms (51.53 GB/s — nhanh hơn 4.72x so với C đơn nhân và 45.51x so với AoS truyền thống).

Q06 Rul có thể thay thế Rust và Go cho phần mềm hệ thống và backend đa dụng không? +

Có — đó chính là mục tiêu của lộ trình 4 cột mốc tiến tới v1.0: Cột mốc 1 (v0.5) bổ sung i64/i32/u8/f32, struct, enum, chuỗi UTF-8, hash map, rẽ nhánh SelectBranch kiểm chứng O(1) và vòng lặp RegionLoop có chứng chỉ dừng; Cột mốc 2 (v0.6–0.7) mở rộng TokenOp và ProofEntry sang cấp phát vùng nhớ Heap (Region) và mượn trường struct; Cột mốc 3 (v0.8–0.9) đưa vào tác vụ nhẹ và channel chuyển giao quyền sở hữu kiểu Go cùng syscall hệ điều hành kiểm soát bởi CapabilityMask; Cột mốc 4 (v1.0) cung cấp trình biên dịch mã máy trực tiếp không cần LLVM cho x86_64, ARM64 và WASI được bảo chứng bởi chứng minh hình thức Kani.