can1357/pon 源码：https://github.com/can1357/pon

pon

pon 是一个用 Rust 编写的 Python 3.14 的 JIT & AoT 原生编译器与运行时。它没有解释器，也没有字节码：每个模块通过 ruff 解析器解析，降级到统一的中间表示（IR），再通过 Cranelift 编译为机器码——要么在进程内即时编译（pon run），要么提前编译为独立的原生可执行文件（pon build）。内存由 Green Tea 垃圾回收器管理，而非引用计数；正确性通过一个基于字节精确差分测试的工具链，针对 CPython v3.14.0 进行验证。

最终目标是成为 Python 领域的 bun/v8：一个通过 CPython 测试套件、多层级 JIT 性能远超 CPython、支持单二进制可执行文件、并内置包管理器和工具链的运行时。该项目正在积极开发中——请参阅状态了解当前已实现的部分与未来规划。

快速开始

# JIT：解析 → IR → Cranelift → 运行，进程内
printf 'def add(a, b):\n    return a + b\n\nprint("hello, world")\nprint(add(2, 3))\n' > hello.py
cargo run -p pon -- run hello.py

# AoT：通过 cranelift-object 生成相同 IR，链接为原生可执行文件
cargo run -p pon -- build hello.py -o hello
./hello

这两条路径输出的结果与 CPython 逐字节一致。这并非愿望，而是符合性套件的退出条件（参见符合性）。

pon run [args]
pon build -o [--allow-dynamic] [--opt] [--target <target>]
pon repl
pon -c 'print(40 + 2)'
pon - < script.py

架构

一个 IR，两个后端，一个运行时 ABI。每一层——基线 JIT、优化 JIT 和 AoT——都降级到相同的 IR，并调用相同的 pon_* 辅助函数：

source.py
   │
   ruff parser (pinned 0.14.0, PythonVersion::PY314)
   AST
   ──> PON IR (pon-ir, every tier uses same IR)
         │
         ├── pon run: pon-codegen ──> cranelift-jit ──> native code in process
         │       tier-0 baseline (all boxed)
         │       tier-1 typed: inline caches, OSR, background compile
         │
         └── pon build: pon-codegen ──> cranelift-object ──> object file ──> linked executable
               │
               pon-runtime (object model, builtins, NULL-sentinel pon_* ABI)
               pon-gc (Green Tea garbage collector)

对象模型： CPython 的堆对象布局，但去掉了引用计数头部。错误通过 NULL 哨兵跨越 ABI，而非使用展开（unwinding）。整数是任意精度的（num-bigint 位于 PyLong 之后）；带标签的小整数快速路径将在类型化层级中出现。

层级化： tier-0 将所有值装箱编译，不收集类型反馈，这是正确性基线（PON_TIER0_ONLY=1 强制使用此层级）。运行时辅助函数从首次执行中收集 FeedbackCell 类型概要；热点函数在后台线程重新编译，正在运行的循环通过栈上替换（OSR）进入优化后的代码。

GC： Green Tea 垃圾回收器拥有所有 Python 对象。tier-0 使用保守的栈扫描，并在安全点通过寄存器刷新跳板（trampoline）实现；类型化层级升级为 Cranelift 精确的用户栈映射。

工作空间

所有依赖项都在根目录的 Cargo.toml 中的 [workspace.dependencies] 中声明一次；子 crate 仅继承（参见 AGENTS.md）。

符合性 & 测试

正确性约定是差分测试：一个语料库模块只有在 pon 产生与 CPython v3.14.0 字节完全相同的输出（TZ=UTC，PYTHONHASHSEED=0）时才通过。通过的集合被锁定到已提交的 floor 文件中，CI 在出现任何低于 floor 的回归时失败。

当前守门程序是 scripts/gate.sh；只有它的输出被视为门控声明：

bash scripts/gate.sh fast       # 构建 + 工作空间测试 + 符合性 floor + AoT floor + ft-stress
bash scripts/gate.sh full       # + cpython-full、基准测试、tier0-only 差分、模糊测试、包管理器 E2E

# 单独测量指标
cargo run -q -p pon-conformance -- --suite cpython --check-floor
cargo run -q -p pon-conformance -- --mode aot --suite cpython-aot-subset --check-floor
cargo run -q -p pon-conformance -- --suite cpython --modules  # 单个模块，差分测试
cargo run -q -p pon-conformance -- --suite fuzz --seed 42 --count 200 --jobs 8

语料库文件一旦落地便不可更改：新的覆盖模块在进入清单之前，必须已通过字节精确比对 python3.14 验证。那些属于 CPython 自身问题（而非 pon 的问题）的分歧，记录在 pon-conformance/divergence-ledger.toml 中，而非掩盖。

包管理器

pon 包含一个 uv 风格的包管理器，基于 pubgrub 解析和标准 pyproject.toml，支持 PyPI 简单索引、wheels、sdists、可编辑安装和 VCS 依赖。其 run 命令通过与直接脚本调度相同的运行时路径执行，同时添加了受管理的导入根目录。它正在积极开发中，尚未集成到运行时门控中。

pon init | add | remove | install | lock | run | list | freeze | show | download | check | cache | env

锁定的工具链

以下锁定项已在工作空间层面确定，并由 Cargo.lock / rust-toolchain.toml 强制执行；不要随意漂移。

状态

当前已验证的内容（全部位于锁定且 CI 检查的 floor 之后）：

• pon run 和 pon build 端到端工作；上面的快速开始是一个经冒烟测试的示例。
• 209 个差分语料库模块在 JIT 下与 CPython 3.14 字节精确一致；其中 172 个也通过 AoT 编译。
• 性能基础设施已就位：后台编译、OSR、内联缓存、类型反馈。

明确尚未完成的内容——这是当前的活跃路线图，按顺序列出：

1. CPython 测试套件（cpython-full）：正在进行中的攻坚；失败案例按波次聚类并逐一消除。
2. 标准库构建：_io/os、math/struct/random、collections/itertools/json、datetime、importlib——每个都以原生模块加上差分语料库模块的方式落地。
3. 性能优化锁定：带标签的小整数快速路径、TLAB 分配、字典快速路径、浮点拆箱、调用/属性特化、生成器层级化——目标是与 CPython 几何平均值相比达到 ≥5×（数值计算 ≥20×）。
4. AoT 对等性提升 直至覆盖完整语料库，同时进行单二进制产品的打磨。
5. 无 GIL / 自由线程运行时强化：线程/GC/信号压力现在在默认运行时路径上，剩余差距由锁定套件跟踪。

语言层面的已知差距将通过上述锁定 floor 逐步消除——已提交的 floor 文件（而非本 README）是权威的兼容性基线。