2-runtime/PC 与帧寻址：调用深度导致 key 长度 O(D)、活跃 key 总量 O(D²) —— 评估 [ctlflow,irseq,params] 三维地址

[miaobyte]

结论先行

三维地址方向正确。定稿形态——ctlflow 独立成段，与 ir 序列之间用 / 分隔：

PC          /vthread/<vtid>/[<帧号>]/[irseq, params]
帧目录       /vthread/<vtid>/[<帧号>]/          → extindex 到 /lib/<func>/
命名局部     /vthread/<vtid>/[<帧号>]/<name>
实参槽       /vthread/<vtid>/[<帧号>]/[0,-j]
系统变量     /vthread/<vtid>/[<帧号>]/‥lib、‥returnpc、‥callpc

三类分隔符各归其位：/ 划结构（vthread → 帧 → 指令槽），[i,j] 坐标段定位指令平面，· 完全不出现在帧结构里、继续专供用户成员键族。

为什么用 / 而不是 ·——· 是成员专用分隔符，帧不是成员。 这不是权衡，是套用 kvspace 自己的公理。kvspace篇-04-系统变量.md「三种键形态：一眼判型」已把三类键的所有权划死（下表按 #66 迁移后的分隔符改写）：

形态	例	性质	所有权
X/名	/vthread/7/[3,0]、/_while_2/[0,0]	结构：帧、指令槽、scope 帧	VM
X·名	/c0·next、frame/obj·prop	用户数据成员（键族）	用户
X/‥名	/vthread/7/‥pc、arr/‥shape	系统变量（影子元数据）	VM

该表第一行原文就把 /vthread/7/[3,0] 列为「结构」。帧号是帧的结构标识，归 VM，不归用户数据平面。若改用 ·，等于把帧塞进用户键族的命名空间，与该表直接冲突，也让「一眼判型」失效——看到 · 不再能断定是用户数据。

为什么 ctlflow 不能挤进同一个坐标段（即 [c,i,j] 三分量写法）：extindex、命名局部变量、‥lib/‥returnpc 三者都要挂在目录上（kvspace-durable/src/kvspace.rs:24-38 validate_dir），而 [c,i,j] 整体是 /vthread/<vtid>/ 下的一个成员名，不构成可挂载的前缀。ctlflow 必须自成一段。

这个形态把 PC 长度从 O(D) 压到 O(1)，同时保留 extindex、Ptr 参数链、逐槽寻址全部不变。

实测补充见 下方评论：[c]·[i,j] 形态的 extindex 在 fs 与 shm 两个后端均静默失效，[c]/[i,j] 形态六项检查全通过，且 runtime 各 keytree 函数逐项不变。但那是当下实现状态、可以被修好；分隔符语义划分是设计公理、修不掉也不该修。即使 kvspace 把 · 目录的 extindex 修好，本方案仍然用 /——该评论中「今天就能用」的选型理由，以本节的分隔符语义为准。

另外需要先澄清一个前提：控制流不加深栈。scope 帧是 rwfunc 帧的平级兄弟（runtime/src/kvcpu.c:203 handle_scope 取的是 FuncFrameRoot 而非当前帧），设计文档也明确「所有 ScopeStmt 为函数体平级兄弟节点」。深度只来自函数调用。但控制流会放大每层调用的字节增量，见下。

---

一、现状：PC 实际怎么长

以 tutorial/02-func/tco_depth.kv 的 tailrec_fact 为例。layout 产物实测（fs:// 后端 dump）：

/lib/tailrec_fact/[1,0]          = goto
/lib/tailrec_fact/_if_2[1,0]     = br
/lib/tailrec_fact/_else_4[3,0]   = tailrec_fact     ← 递归调用点
/lib/tailrec_fact/_else_4[4,0]   = goto _merge_5

handle_call 直接把当前 PC 当作被调帧根（runtime/src/kvcpu.c:302 char *frame_root = strdup(pc);），而递归调用点位于 _else_4 scope 内，于是运行时 PC 链是：

d=1  /vthread/1/[1,0]/[3,0]                                       22 B
d=2  /vthread/1/[1,0]/[3,0]/_else_4/[3,0]                         36 B
d=3  /vthread/1/[1,0]/[3,0]/_else_4/[3,0]/_else_4/[3,0]           50 B

每层 +14 B（/_else_4 8 B + /[3,0] 6 B）。若递归调用点在函数体顶层而不在 if/else 内，增量是 6 B——这就是「控制流放大每层增量」的确切含义：它不增加深度，但让每层的路径段翻倍。

PC(d) = 22 + 14(d - 1)。MAX_STACK_DEPTH = 256（runtime/src/runtime_internal.h:53）时 PC ≈ 3.5 KB。

二、成本模型

帧内每个键都是 帧根 + /名，即每个键都是 O(D)。tailrec_fact 一帧约 15 个键（N/acc/r/acc1/acc1_m/n1 + ‥lib/‥returnpc/‥callpc + [0,-1]/[0,-2]/[0,1] + 两个 scope 帧各自的 ‥callpc/‥returnpc）。

活跃栈的键字节总量：

Σ(d=1..D) 15 × (22 + 14(d-1)) ≈ 105 D²

D	PC 长度	活跃 key 字节总量
10	148 B	~10 KB
100	1.4 KB	~1 MB
256	3.5 KB	~6.9 MB

纯 key 字符串，不含 value。这是 D² 项，不是常数项。

三、depth 耦合的三个热路径

1. 每条指令写一次 O(D) 字符串。kvlangVthreadSet 把完整 PC 写进 ‥pc（kvcpu.c:393/400/408/424/591/596），每条指令一次。
2. 每条指令读四次。循环顶 kvlangVthreadGet（kvcpu.c:549）+ 执行后再一次（kvcpu.c:645），各取 ‥pc/‥status 两个键。
3. 每条指令解码探测 257 个槽。runtime/src/rwir.c:87 nslots = 1 + 2 * MAX_PARAMS，MAX_PARAMS = 128。fs 后端 get 对每个 key 做 join_path(prefix, k) 再落盘探测（kvspace-durable/src/fs/kvspace.rs:360-392），未命中且帧有 extindex 时再 join 一次走 ext 回落。于是每条指令构造 ~500 个长度为 O(D) 的字符串。D=100 时约 38 KB 字符串构造 / 指令。

第 3 点是独立缺陷（应按签名的 nr/nw 精确取槽，而非盲扫 128 对），但它是把 PC 长度问题放大 257 倍的乘数。建议单独开 issue，与本 issue 并行修。

此外 ResolveWriteSlot（runtime/src/builtin.c:143-183）在 fallback 路径上调用 FuncFrameRoot 两次（145 行、178 行），每次都是自帧根向上逐级 KV get 探 ‥lib。

四、为什么 ctlflow 要独立成段

本表针对 [c,i,j] 三分量挤成一个成员名 的写法。至于把 ctlflow 拆出来但用 · 分隔（[c]·[i,j]）——那在类型上是成立的，· 本就是合法目录分隔符，被否掉的理由是分隔符语义（帧是结构不是成员，见开头），不是这张表。

现有机制	依赖	[c,i,j] 下能否成立
指令取数	帧根目录 extindex → /lib/<func>/（kvcpu.c:307）	✗ validate_dir 拒绝非目录路径，坐标分量不是前缀
命名局部变量	帧根/<name>（builtin.c:145-149）	✗ 坐标里放不下标识符
系统变量	帧根/‥lib、‥returnpc、‥callpc	✗ 同上
Ptr 参数链	帧根/<name> → ext → Ptr("[0,-1]") → 帧根/[0,-1]	✗ 依赖前两条

补充一点坐标语义的现存瑕疵：kvspace-durable/src/coord.rs 的 parse_coord 只接受非负整数，负的读参坐标 [0,-1] 解析失败后退化成字典序而非 row-major 数值序。三维方案若把 params 放进坐标第三维，这个瑕疵会跟着进去。

五、推荐方案

分两步，每步独立可验证。

步骤 1：label 降为整数 irseq 偏移，删除 scope 帧

scope 帧不提供任何作用域。 所有变量读写都定位到 rwfunc 帧——读走 resolve_read_path → FuncFrameRoot（kvcpu.c:126），写走 ResolveWriteSlot → FuncFrameRoot（builtin.c:145）。scope 帧里只有 ‥callpc 和 ‥returnpc 两个续体记录键。所以把它拍平语义零损失。

layout 侧：把 /lib/f/_while_2[i,j] 合并进 /lib/f/[i,j] 单一指令平面，label 在 layout 期解析为整数行号，goto/br 的读参直接是目标 irseq（label 名保留在 /lib/f/‥labels/<name> 供调试）。

收益：

• goto/br 从「建帧 + get ‥callpc + set ‥callpc」（kvcpu.c:216-238，每次进入 label 都付）变成一次 irseq 赋值，0 次额外 KV 操作。一轮 while 循环现在要走 5 条指令（cond / br / body×2 / goto），其中 br 和 goto 各带 2 次 KV 往返，全部消掉。
• runtime/src/rwir.c:22-64 scope_prefix_and_base 整个删除。顺带说明：它支持的嵌套 scope 前缀（_while_2·_if_1）是死代码——handle_scope 恒以 FuncFrameRoot 为父，scope 永远只有一层。
• handle_scope / handle_scope_return（kvcpu.c:201-243、163-177）删除，ext_kind 分支（kvcpu.c:19-30、588）删除。
• 每层调用的 PC 增量从 14 B 回落到 6 B。

步骤 2：帧根改为扁平帧号

/vthread/<vtid>/[<帧号>]/[irseq, params]

帧号取调用深度，不需要计数器：kvlang 无闭包/协程，帧严格栈式，深度 d 的帧恒为 /vthread/7/[d]/，return 即 del_tree 该目录。帧号写成坐标段 [d] 而非裸数字 d：cmp_coord 对坐标段按数值 row-major 排序且恒排在非坐标段之前，于是 kvspace list /vthread/7/ 直接给出按栈序排列的帧列表。

• PC 恒长：/vthread/7/[256]/[3,0] = 23 B，与深度无关。
• stack_depth（kvcpu.c:13-17，现在靠数 [ 字符）变成读一个整数，O(1) 且精确。
• extindex、‥lib/‥returnpc/‥callpc、命名局部、Ptr 三跳链全部原样保留——帧根仍是目录。
• FuncFrameRoot 的向上探测（builtin.c:88-104）消失：步骤 1 之后不存在 scope 帧，当前帧就是 rwfunc 帧。
• 活跃 key 字节总量从 O(D²) 降到 O(D)。

唯一前提假设：帧不逃逸。若将来引入闭包或协程使帧生命周期超出父帧，帧号 = 调用深度 失效，届时需换成 vthread 级单调计数器（多一个可变计数键）。这个假设需要明确记录。

六、代价：会失去什么

deepx-design/.claude/writing-standards.md 把 C2「路径深度即调用栈深度」 列为对外文章必须传达的核心概念。本方案下：

• C3「PC 是路径字符串」保留——PC 仍是路径，跳转仍是字符串拼接。
• C2 形式改变但语义更强：深度不再是路径的 / 层数，而是路径里那一段帧号，从「隐式且 O(D) 才能算出」变成「显式且 O(1) 可读」。文档口径需相应改写为「路径中的帧号即调用栈深度」。
• C6「崩溃可恢复」保留，但重建完整调用链从「读一个 PC 字符串即得全链」变成「沿 ‥returnpc 走 D 次读」。仅发生在恢复路径，非热路径。若不可接受，可在 vthread 级冗余一个 ‥stack 全链字符串。
• 可观测性：kvspace tree /vthread/7/ 从嵌套调用树变成扁平的编号帧列表。对 dashboard 而言这更接近一个真实的栈视图，但确实是外观改变，kvlang-device-screen 需同步。

七、关联

• kvlang 相对路径的寻址方式，以解决长key寻址慢的问题 #61「kvlang 相对路径的寻址方式，以解决长key寻址慢的问题」——同一个根问题（长 key 寻址慢）的另一条路径。相对寻址只压传输量，不改 O(D²) 的存储量；本方案从源头消掉 D 这一维。两者不冲突，但如果本方案落地，kvlang 相对路径的寻址方式，以解决长key寻址慢的问题 #61 的必要性大幅下降，建议先决策本 issue 再定 kvlang 相对路径的寻址方式，以解决长key寻址慢的问题 #61 去留。
• 需要同步的文档（p9 双向同步）：doc/kvlang-design-and-implementation/parser&runtime-01控制流篇.md（scope 帧模型整节作废）、kvspace篇-03-代码指令的布局格式.md、kvspace篇-04-系统变量.md、.claude/writing-standards.md 的 C2 口径。

八、待决策

1. 步骤 1 与步骤 2 是否合并为一次不兼容变更？（p5 不向后兼容，倾向合并，一次改到最终态）
2. 帧号 = 调用深度 是否接受「帧不逃逸」这条前提？还是直接上 vthread 级计数器留出闭包空间？
3. C2 的对外口径改写谁来定？涉及 README / article 已发布内容。
4. rwirext C ABI 是否会破？ 已核查：runtime-rwirext_example/ 下 rust/term、go/json、py/numpy 三个扩展均把 PC 当不透明字符串，只构造 /vthread/<vid>/‥pc 这类 vthread 级键（term/src/main.rs:231、json.go:623、numpy.py:320），无一解析 PC 内部结构。kvlang_rwirextNextPc 新形态下仍是纯字符串操作（解析 [i,j] 后 i+1），ABI 签名与语义均不变。此项无阻塞。

[miaobyte]

更正 + 实测：[ctlflow]·[a,b] 与 [ctlflow]/[a,b] 两种写法

先更正上文 §4 的错误判断

我在 §4 写「坐标分量挂不了 extindex，因为 validate_dir 要求路径以 / 或 · 结尾」——这条推论本身就自相矛盾，是错的。· 就是 OBJ_SEP（kvspace-durable/src/const.rs:40），validate_dir 明确接受它，split_index 的文档注释更是直说「m·[0,1] 切成父目录 m· + 成员名 [0,1]」。所以 /vthread/7/[3]· 在设计上是合法目录，[ctlflow]·[a,b] 的写法在类型上成立。

结论要靠实测，不能靠推。下面是对着真实 C ABI 跑的探针结果。

实测方法

约 100 行 C，直接链 kvspace C ABI（kvspaceMkindex / kvspaceMkindexExt / kvspaceSet / kvspaceGetBatch / kvspaceList / kvspaceDelTree），模拟一个帧目录的完整生命周期，六项检查：

1. 帧目录能否 mkindex
2. 能否对它建 extindex → /lib/f/
3. GetBatch(prefix=帧目录, "[1,0]") 能否走 ext 回落取到指令
4. 帧内局部写（[0,-1] 实参槽 / 命名局部 acc1 / ‥lib / ‥returnpc）能否读回
5. 局部写是否误遮蔽 /lib 同名 key（N 应仍走 ext）
6. RmindexExt + DelTree 销毁帧，且不得伤到 /lib/f

结果

检查	[3]·[i,j] (fs)	[3]·[i,j] (shm)	[3]/[i,j] (fs)
1 mkindex	✅ rc=0	✅ rc=0	✅
2 extindex	✅ rc=0	✅ rc=0	✅
3 ext 回落取指令	❌ None	❌ None	✅ "add"
4 帧内局部写读回	✅	✅	✅
5 命名参数走 ext	❌ None	❌ None	✅
6 DelTree 不伤 /lib	—	—	✅ /lib/f 幸存

· 形态在 fs 与 shm 两个后端都断在同一处：extindex 建得成、返回 rc=0，但读的时候永远不回落。 建索引静默成功、解析静默失效——按 p1「绝不容许代码以奇怪的方式成功运行」，这本身就是必须杀掉的牛。

两个后端的根因（各不相同，症状一致）

durable / fs：resolve_parent（kvspace-durable/src/fs/kvspace.rs:210-226）先 strip_dir_suf 剥掉尾分隔符，最后却无条件 result.push_str(DIR_INDEX_SUF) 把 / 补回去——丢掉了「剥掉的是哪一种分隔符」这个信息。于是 ext_index("/vthread/7/[3]·") 把 marker 写到了 /vthread/7/[3]/__extindex__，而数据落在 /vthread/7/[3]·/。文件系统实景：

/vthread/7/[3]/__extindex__      ← marker 写到了这里（错）
/vthread/7/[3]·/[0,-1]           ← 数据在这里
/vthread/7/[3]·/acc1
/vthread/7/[3]·/‥lib
/vthread/7/[3]·/__map__

读路径 prefix_ext("/vthread/7/[3]·") 去 [3]·/__extindex__ 找，扑空 → 无回落。

kvspace-c / shm：ext 回落走 psplit（kvspace-c/src/kvspace.c:562-574），而 psplit 只 strrchr(k, '/')，根本不认 · 边界。/vthread/7/[3]·[1,0] 被切成父目录 /vthread/7/ + 成员名 [3]·[1,0]，去查 /vthread/7/ 的 extindex，自然扑空。讽刺的是紧挨着的 bad_dir_prefix（同文件 575-580 行）注释写着「对齐 durable validate_dir」并明确接受 · 结尾前缀——校验层认 · 是目录，解析层不认。

顺带一个 kind 误判：· 目录下写坐标成员会触发 __map__ 标记（fs/kvspace.rs:470-487），把帧目录标成 strkeymapindex。实测 __map__ 内容是 1——因为 parse_coord（coord.rs）只收非负整数，读参坐标 [0,-1] 解析失败后 grow_coord_dims 退化成「1 维、长度=成员数」。即 · 形态下帧目录会被错误地标成一个 1 元素的 ndarray。

结论：采用 [ctlflow]/[a,b]

/vthread/<vtid>/[<帧号>]/[irseq, params]

理由不是「· 不能用」，而是 / 今天就能用，· 要先修两个后端的 bug 才能用，而修完之后两者收益完全相同（都是常数长度）。按 p3「不为错误架构产生一堆修补代码」，没有理由为了 · 先去补两处解析。

它同时是改动最小的形态——现有帧根本来就已经是一个坐标段（/vthread/1/[1,0]），这个方案只是把该段的语义从「调用点 PC」换成「帧号」，并停止嵌套：

runtime 现有函数	新形态下
kvlangKeytreeFrameRoot（rfind("/[")）	不变，/vthread/7/[3]/[5,0] → /vthread/7/[3] ✅
kvlangRwirNextPc（末段 addr0 + 1）	不变 ✅
kvlangKeytreeVtidFromPc	不变 ✅
kvlangKeytreeIsEntryPc（/[1,0] 结尾）	不变 ✅
extindex 帧根 → /lib/<func>/	不变，实测通过 ✅
命名参数 Ptr 三跳链	不变，实测通过 ✅
[0,-j] 实参槽不与 /lib 冲突	不变，实测通过 ✅
stack_depth（数 [ 字符）	改为读帧号坐标，O(1) 且精确
handle_call 的 frame_root = strdup(pc)	改为 /vthread/<vtid>/[<depth+1>]
scope_prefix_and_base / FuncFrameRoot	由 §5 步骤 1 删除

额外收益：[3] 是坐标段，cmp_coord 对坐标段按数值 row-major 排序且恒排在非坐标段之前，所以 kvspace list /vthread/7/ 直接给出按栈序排列的帧列表。实测 List(/vthread/7/) 在帧销毁前后分别是 [[3]/] 和 []，干净。

衍生 issue（建议单开，与本 issue 解耦）

0-kvspace/ExtIndex 在 ·目录上静默失效（fs 写错 marker 位置、shm 不认· 边界）

无论本 issue 走哪条路，这都是 kvspace 自身的缺陷：validate_dir / bad_dir_prefix 宣称 · 是合法目录分隔符，但 extindex 的建立与解析都不遵守。要么修（resolve_parent 记住剥掉的分隔符种类；psplit 认 · 边界），要么在 ext_index 入口对 · 结尾路径直接报错——当前的静默成功是最坏选项。· 目录下坐标成员被误标 strkeymapindex / dims 退化是同一处的次生问题。

---

本条更正取代原 issue §4 的判断，§5「推荐方案」步骤 2 的形态相应固定为 /vthread/<vtid>/[<帧号>]/[irseq,params]。

[miaobyte]

实测复现：深度递归的 O(D²) 成本（2026-08-30，C runtime + shm 后端）

按本 issue 的成本模型做了实测验证，结论与 §二 一致。

深度 → 耗时（tail 递归 ，每次调用 1 帧）

深度 N	耗时
10	0.43 s
20	1.94 s
40	11.3 s
60	34.4 s（冷）
200	>120 s 超时（MAX_STACK_DEPTH=256）

冷/热 mmap 差异大（同深度 60 暖跑约 4 s），但增长趋势明确是超线性，与活跃 key 字节 ≈ 105D² 的模型吻合。

PC 键长实测

深度 58 时最深 key（运行中 DFS 采样）：

/vthread/1/[1,0]/[1,0]/_else_4/[2,0]/_else_4/[2,0]/… ×28 /_then_3[0,-1]/   = 415 字符

即每层约 +14 B（scope 内调用点），与 §一 的 PC(d)=22+14(d-1) 一致；D=256 外推 ≈ 1.8–3.5 KB/键。

结论

• 帧内每个键 O(D)，活跃栈键字节 O(D²)，深度 256 理论总量 ~6.9 MB 纯 key（不含 value）——实测被这个模型主导。
• 三个热路径（每条指令写 1 次 O(D) ‥pc、读 4 次 O(D)、解码盲扫 257 槽每槽 O(D)）共同放大，深度 60 已是秒级。
• 附带确认：fs 后端同程序报 TypeError: None in comparison（与 shm 行为不一致，独立问题，另记）。

本 issue 的 §五 两步方案（label→irseq 拍平 scope + 帧号 [d] 扁平化）+ 257 槽盲扫修复（按 nr/nw 精确取槽），正是消除上述 O(D²) 的路径。

[miaobyte]

修正上文一处被转义吞掉的措辞：「深度 → 耗时（tail 递归 bench(N,0)，每次调用 1 帧）」——即每深度 N 尾递归调 N 次、活跃 N 帧。

[carsontung666]

Go + ART 再跑了一轮，程序多一些。before 是 a90dd46 嵌套 PC，after 是现在 /vthread/<id>/[<d>]/[irseq,j]，3 次中位数。

tutorial 129 个：总时间 14268→12019 ms，几何平均 1.14×。

	before	after
recursion.kv	363 ms	108 ms
100_same_tree	332	100
012_int_to_roman	331	125
104_max_tree_depth	123	55
094_inorder	80	36
fizzbuzz	215	107
prime_sieve	932	1202

sieve 这种没几下控制流的，没什么差，有的还慢一点。hello/if 那种十几 ms 的别看。

rec 写在 else 里：

N	before	after
10	220 ms	60 ms
20	876	85
30	2470	172
40	4013	174
50	7690	224

then 里、非尾也差不多。N=40：then 4362→200，非尾 5031→170。fib(12) 11619→2055。N=50 的 RSS 23→14 MiB。

调用链（没有 else 嵌套也会快）：8×40 是 1135→728，16×40 是 3132→1398，32×20 是 5486→1425。嵌套 if 8 层 ×200 圈 12590→5462。

while 还是 Decode 在撑着：

	before	after
while 200	713 ms	638 ms
while 2000	6237	5671
if+while 2000	14145	10799
nest-while 50×50	8721	4950

layout 11–34 ms，两边一样。lib 平了（while.kv 里那些 _while_N key 80→0），总字节没少，labels 还在。

[carsontung666]

控制流执行侧补完了。if / while / for / break / continue lower 完只剩 goto/br，目标是 int64 指令号；跑的时候只改 PC 的 [irseq]，不为块建帧，也不给块 extindex。vthread 下面没有 _then_ / _else_ / _while_ 这种目录。

abs：

rwfunc abs(x:int64) -> (r:int64) {
    if (x < 0) { 0 - x -> r } else { x -> r }
}

1: goto 2
2: int64·lt x 0 -> _1
3: br _1 4 6
4: int64·sub 0 x -> r
5: goto 8
6: = x -> r
7: goto 8
8: return

while 1..n：

1: = 0 -> acc
2: = 1 -> i
3: goto 4
4: int64·le i n -> _1
5: br _1 6 9
6: int64·add acc i -> acc
7: int64·add i 1 -> i
8: goto 4
9: return

break 就是 goto 到 exit，continue 就是 goto 回条件。break 那个测例里是 9: goto 6（6 是 return），continue 是 11: goto 4。

执行（fs；崩在 1÷0 时看帧）：

测	结果
if then，0-5 取绝对值	打印 5
if else	打印 4
then 里 1÷0	PC /vthread/1/[2]/[4,0]，只有 [1][2] 两帧
else 里 1÷0	PC /vthread/1/[2]/[6,0]，还是 [1][2]
while 1..10	55
while 里 1÷0	PC /vthread/1/[2]/[7,0]，[1][2]
break 出循环	5
continue 跳过 3	acc=12
两层 while + if 里 1÷0	PC /vthread/1/[2]/[15,0]，还是 [1][2]
tutorial if/while/guess/classify/for	期望输出都对
sieve(30) 里的 break	打出 prime 29

layout 10 个 + 执行 15 个，全过。嵌套再深也还是当前函数那一帧。

[miaobyte]

关联 #194：prime_sieve bench 量化了同一条 runtime 链路的正交成本维度——每操作一次 KV 往返。同逻辑试除法 kvlang(shm) 33.37 s、Python 240.8 µs、Rust 24.2 µs（慢 Python ~138,500×）。本 issue 优化的是单次往返的 key 体积（O(D)/O(D²)），#194 记录的是往返次数×单次延迟，两者正交、同源于「PC/帧/局部全落 KV 树」。