[0x00..0x3F] magic = b"RUL\x00\x01\x00\x00\x00" · 128비트 바이너리 IR

AI 에이전트를 위한 128비트 바이너리 프로그래밍 언어.

AI는 숫자로 생각하고 CPU는 바이너리로 작동합니다. 하지만 C, Go, Rust는 AI에게 인간의 텍스트를 타이핑하게 만들고 컴파일러가 의도를 추측할 때까지 몇 초씩 기다리게 합니다. Rul (.rl)은 이 텍스트 중개자를 제거했습니다. AI가 알고리즘, CPU 스케줄, 메모리 안전 티켓을 담은 고정 16바이트 바이너리 블록을 직접 출력합니다. 결과: 5.8 ns 안전성 검증, 6.4 µs 독립 실행 파일 컴파일, 수동 작성된 C보다 4.72배 빠른 실행 속도를 달성합니다.

10초 만에 이해하는 제1원칙 · 텍스트 중개자를 제거하라

✗ 기존 방식 (C / Go / Rust) AI 사고 (숫자) → 인간 텍스트 타이핑 → 컴파일러 구문 분석 및 의도 추측 (수 초 소요) → 기계어 (0/1)

✓ RUL (.rl) 제1원칙 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 · 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] 128비트 프레임

16 Bytes

모든 명령이 고정 바이너리 블록 · 텍스트 파싱 0 ms

[0x50] 명령어당

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비트 워크벤치

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

하나의 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바이트 바이너리 프레임 및 어셈블리와 동기화됩니다

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] 1바이트 하드웨어 스케줄 변이

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

단 1바이트(Byte 2)만 바꾸세요. 수동 작성 C보다 4.72배 빨라집니다.

실제 워크로드: 10,000,000개의 부동소수점(80 MB 배열) — 1000.0 초과 값 필터링 후 제곱하여 합산. 아래에서 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() 1코어 AoS + 힙 할당

70.66 ms 1.13 GB/s 0.10x

[B] 표준 Rust SoA (filter().map().sum()) 1코어 SoA 이터레이터 체인

19.12 ms 4.18 GB/s 0.38x

[C] 수동 작성 C/Rust 8어큐뮬레이터 SoA 1코어 8레인 루프 언롤링 (기준선)

7.32 ms 10.92 GB/s 1.00x (Baseline)

[D] Rul (.rl) Tier 2 융합 SIMD (0x11) 1코어 L1 타일 SIMD (SimdStream)

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

[E] Rul (.rl) Tier 2 멀티코어 (0x12) 전체 코어 (1바이트 스케줄 변이)

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

[F] Rul (.rl) Tier 2 멀티코어 + ZoneMap 전체 코어 + O(1) 콜드 타일 스킵

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

딥 파이프라인 증명: 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가지 제1원칙 메커니즘

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

제1원칙은 단순하게. 실리콘 실행은 수학적으로 정확하게.

기존 언어는 기계가 인간의 글을 읽고 의도를 추측해야 하므로 컴파일이 느립니다. Rul은 4가지 자명한 메커니즘으로 추측을 완전히 제거합니다:

01 · 바이너리가 곧 유일한 진실의 원천 src/bytecode.rs

1. 텍스트 파싱 제로 (구문 오류 0%)

세미콜론이 빠지기 쉬운 수천 글자를 타이핑하는 대신, AI는 16바이트 바이너리 블록을 직접 방출합니다(또는 ~8.8 µs에 .rls 어셈블). 1,000만 개의 숫자를 처리하는 7단계 파이프라인은 .rl에서 단 208바이트이며, 817바이트 독립 Linux ELF64 실행 파일로 컴파일됩니다.

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) ✓ 공유 읽기 (버전 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로 각 단계의 정확한 min, max, sum, NaN=0을 검사하세요.

인간이 계약 정의 → AI가 .rl 재생성

검증 + 컴파일 총 ~12 µs 소요

29 옵코드 사양 보기 →

[0x180] 시스템 비교 매트릭스 & AGENT MCP

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

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 보조 테이블 검증
검증 + 컴파일 시간	수 초	1초 미만 ~ 수 초	수 초 ~ 수 분	~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 서버로, 자율 AI 에이전트에게 검증, 차등 테스트, 오토튜닝 및 AOT 컴파일을 위한 6가지 네이티브 도구를 직접 제공합니다.

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 로드맵

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

검증된 컬럼형 엔진(v0.4)에서 범용 시스템 프로그래밍 언어(v1.0)로

실제 실리콘에서 16바이트 바이너리 포맷을 먼저 입증하기 위해 v0.1~v0.4를 배열 및 벡터 파이프라인(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] 서로소 구조체 필드 변이 및 제로카피 서브슬라이스 라이프타임을 명령어당 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)

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

자주 묻는 질문 — 쉬운 원리부터 깊은 시스템까지

엔지니어, 연구자 및 AI 답변 엔진을 위해 제1원칙에 기반한 명확한 설명과 정확한 실증 측정치를 제공합니다.

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은 어떻게 느린 빌림 검사기 없이 명령어당 ~5.8 ns 만에 Rust급 메모리 안전성을 검증하나요? +

각 메모리 버퍼(Arena)를 버전 1부터 시작하는 번호표가 있는 방이라고 생각하세요. 여러 명령어가 공유 ReadLease(0b01) 티켓을 사용해 동시에 버전 1을 읽을 수 있습니다. 명령어가 AffineConsume(0b10)으로 버퍼를 제자리에서 수정하면 가변성을 확인하고 방을 버전 2로 올립니다. 이전 버전 1 티켓을 가진 후속 명령어는 단일 순방향 패스(~5.78 ns/노드) 동안 입구에서 O(1) 시간에 즉시 거부됩니다 — 수 초가 걸리는 빌림 검사기 솔버가 필요 없습니다.

Q03 인간이 .rl 바이너리 파일을 직접 작성하지 않는다면 엔지니어링 팀은 어떻게 디버깅하고 유지보수하나요? +

의사가 X-레이 사진을 직접 손으로 그리지 않고도 판독하듯, 인간은 바이너리를 타이핑하지 않고도 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 에이전트를 위해 텍스트 언어를 대체하도록 설계되었다면 왜 Rul 툴체인은 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 네이티브 백엔드를 제공합니다.