 yml2213
|
eed7004754
|
chore(vm): 归档解释器 tdc_vm_run.py 到正确语义 (VM 返回 = 栈顶/切片)
做了什么:
- 修正 VM 返回语义: `A ? (E.pop(), E.slice(3+VM.v)) : E.pop()` (闭包调用返回栈顶)
- JArr 缺键返回 undefined; E 初值 [this]=全局; CALL_FUNC 的 this=c
为什么:
- 该工具已判定为"用 Python 复刻 JS 运行时"的弯路(AGENTS.md §2.3 铁律2 打地鼠陷阱)
- 但已实现的 58 个 opcode 语义 + 诊断钩子仍有储备价值, 故归档而非删除(§1.4)
怎么验证:
- py_compile 通过; 与真值 PC 轨迹对拍仍显示前 713 步一致(未继续推进, 按新路线改走 lift)
|
2026-10-11 22:15:51 +08:00 |
|
|
yml2213
|
9008af0d18
|
fix(vm): 3 处保真修复 + 精确定位到模块实参为 null
做了什么:
- JArr.__getitem__ 缺失键返回 undefined (JS 语义), 原来返回 Python None
- E 初值 E[0]=[this], 顶层 this=全局对象 c (原来错写成 None)
- MAKE_REG_PROP_REF / CALL_METHOD / closure 调用 增加 DBGCALL 诊断输出
为什么:
- 用 PC 轨迹对拍逐条缩小: 前 713 步一致, 分歧在 @206 CALL_METHOD
- 根因链: @45631 CALL_FUNC(模块工厂) 的实参是 [null] -> 参数 r3=[null]
-> 闭包 @20 捕获 r6=父r3 -> E[6][0]=null -> ref=[null,'call'] -> 调用不到
怎么验证:
- node tools/tdc_trace.js ... -> 19266 步(真值); 我们仍 739 步
- 分歧点/根因链见上 (已用 DBGCALL 定位到具体指令与寄存器)
下一步线索: 追 "谁把该实参压成了 null" (候选: PUSH_NULL(29) 被误用, 或某次属性读取应得对象却拿到 null)
|
2026-10-11 22:07:16 +08:00 |
|
|
yml2213
|
3f91b0a4e3
|
feat(vm): PC 轨迹对拍工具 + 2 处语义修复(定位到首个执行流分歧)
做了什么:
- 新增 tools/tdc_trace.js: 给分发器 M=G[z[H++]]() 打补丁, dump 真实执行 PC 序列
- tdc_vm_run.py: 新增 TRACE_FULL 全量 PC 轨迹; 子 VM 共享 pcs/events(轨迹是全局的)
- 修复 CALL_FUNC 的 this 绑定: 真实语义 fn.apply(c, B) -> this = c (原来传 None)
- DBGCALL 调试输出(callee 类型/closure 异常/ref 与栈尾)
为什么:
- 单靠读语义会无限试错; PC 轨迹对拍能一步定位首个分歧
怎么验证:
- node tools/tdc_trace.js tcaptcha/core_js/tdc_sample.js -> 真实 19266 步
- 我们的解释器 739 步; 逐条 diff 后:**前 713 步完全一致**
- 首个分歧 @step714: real 进入 @1544, 我们 fall-through 到 @208
对应指令 @206 CALL_METHOD [4]; 我们的 ref=[None,'call'] (base 为 None),
真实应为一个可调用对象 -> 说明某个寄存器在我们这边是 None
|
2026-10-11 22:04:44 +08:00 |
|
|
yml2213
|
1fbd8f46f5
|
fix(vm): 修正解释器 4 处保真度问题 + 增加事件追踪
做了什么:
- E 初值改为 [[this],[{}]] (与 VM 源码默认一致)
- Stub 改为真正保存被赋属性 (模块工厂挂在对象上, 丢弃就找不到模块)
- Object/Array/String/... 改为 HostFn, new 时真正构造容器
- getprop/setprop 采用 JS 非严格语义 (原始值: 读=undefined, 写=静默忽略)
- 新增 TRACE=1 事件追踪 (CREATE_CLOSURE/CALL_*/RET_TRUE) 与模块表收集
为什么:
- 这些是解释器与真实 VM 保真度不符的根因, 导致顶层跑完却收不到任何模块闭包
怎么验证:
- py_compile 通过; TRACE=1 跑出 66 条关键事件(其中 CREATE_CLOSURE ~65)
- 现状: 仍只跑完顶层引导(739 步), 模块表为空 -> 待用 PC 轨迹对拍定位首个分歧
|
2026-10-11 22:02:20 +08:00 |
|
|
yml2213
|
70f2ece32c
|
docs(vm): 新增 Chaos VM 规范 + WIP 纯 Python 解释器
做了什么:
- 新增 tcaptcha/VM_SPEC.md: 从源码/反汇编事实整理 VM 全套规格
* §1 架构(VM(H,z,c,E,I,D,U,C), c=window, 主循环 M=G[z[H++]]())
* §2 数据模型(E 一物两用=寄存器区+求值栈; 寄存器单元 E[i][0]; 引用=二元数组 [base,key])
* §3 完整 opcode 表(70 槽/58 handler/12 空洞, 附 handler 源码与 argc, 由 AST 自动导出)
* §4 闭包与调用(CREATE_CLOSURE 动态布局, caps 共享单元, CALL_FUNC/METHOD 的 this 绑定)
* §5 引导流程(实测顶层只注册模块) §6 宿主与驱动(c 即 window, 环境全走 c)
* §7 工具链映射 §8 解释器路线图(已完成①-④, 未完成⑤模块系统+宿主驱动)
- 新增 tools/tdc_vm_run.py: 58 个 opcode 的具体解释器 + 宽松 JS 宿主 (WIP, 跑通顶层引导)
为什么:
- 之前"没头绪"的根因是数据模型(E 一物两用/寄存器单元/引用二元数组), 必须写成确定规格
- 并定位真正的卡点: 不在 VM 而在"模块系统 + 宿主调用序列"
怎么验证:
- tools/tdc_vm_run.py 跑 739 步后 RET_TRUE (仅顶层引导), 与 CFG 可达性一致
|
2026-10-11 21:59:06 +08:00 |
|