档案库 · 硬件与设备 · 技术决策 · 2025–2026
RunPyXL 押注 Python 属于硅片：FPGA 演示获 983 个 HN 点赞
一位独立开发者用 FPGA 处理器直接执行 Python，无需虚拟机/即时编译/C 语言；480ns GPIO 往返时间比 MicroPython 快约 30 倍，获 983 个 HN 点赞。
RunPyXL
做的是什么生意
RunPyXL is a solo effort to build a custom processor that runs Python directly in hardware — no VM, interpreter, JIT, OS or C — for deterministic, low-latency embedded and real-time systems; as of the material it is an early proof of concept with an early-access contact list, not a shipped product.
起因
The builder, who posts on Hacker News as hwpythonner, designed the processor from scratch because conventional CPUs are optimized for static, register-based C/C++, while Python's stack-based, dynamically typed execution maps poorly onto them and wastes work on interpreter overhead, runtime type handling and reference counting. He built the full stack himself — a Verilog processor with a custom stack-based ISA ('PySM') inspired by CPython bytecode, plus a Python toolchain that compiles .py into CPython bytecode, then PySM assembly, then a binary that runs on an Arty-Z7-20 FPGA. He had considered turning PyXL into a RISC-V extension early on but chose a clean-slate design so he could rethink Python's execution model rather than adapt a register-based architecture.
经过
He launched the GPIO demo as a Show HN on 2025-04-28 and it drew 983 points with 265 comments. In-thread he said the goal is C-like or close-to-C performance with Python's ease of writing; the ISA is deliberately in-order with no speculative execution to keep timing predictable and avoid a class of side-channel issues; he targets CPython bytecode rather than the AST because bytecode changes are usually contained to VM behavior; and he called dynamic memory allocation and garbage collection under real-time guarantees the biggest challenge, with the FPGA a prototype and ASIC the eventual route. Commenters pushed back hard: asford argued the benchmark was misleading because MicroPython's 'viper' decorator already compiles hot paths to native machine instructions and should be the baseline, and others noted CPython bytecode drifts across versions (3.10's relative jumps, 3.11's MAKE_FUNCTION change), leaving a fixed-hardware target fragile. The launch post promised full technical details at PyCon 2025.
还没有结局，它还在跑。
背景
RunPyXL 是一个概念验证的定制处理器，在硬件中直接执行 Python：没有虚拟机、解释器、即时编译、操作系统或 C 语言。Python 工具链将 .py 文件编译为 CPython 字节码，将其翻译为自定义汇编（PySM），并生成在流水线处理器上运行的二进制，该处理器从零开始构建并在 Zynq-7000 FPGA（Arty-Z7-20）上以 100MHz 频率进行原型验证；ARM CPU 仅处理设置和内存，而 Python 代码本身在硬件核心中完全运行。
该赌注是 Python 语义属于硅片：传统 CPU 针对静态、基于寄存器的 C/C++ 进行了优化，而 Python 基于栈、动态执行浪费了解释器开销和运行时类型检查的周期。开发者独自编写了完整技术栈——带有自定义基于栈的 ISA（PySM）的 Verilog 处理器以及 Python 工具链，将 .py 编译为 CPython 字节码，然后转换为 PySM 汇编，最后在 Arty-Z7-20 FPGA 上运行的二进制——并拒绝了一个早期的 RISC-V 扩展想法，选择从零设计，以便重新思考 Python 的执行模型。
于 2025-04-28 以 Show HN 发布，带有一个测量——GPIO 往返时间 480ns，与 MicroPython PyBoard 的 14.7µs 相比，大约快 30 倍——演示获得 983 分和 265 条评论。在讨论串中，他提出目标是达到 C 的性能，同时保持 Python 的易用性，并为其选择辩护：无推测执行，内存管理是最大的开放挑战，ASIC 是最终目标。怀疑者反驳说基准不公平——MicroPython 的 viper 已经将热点路径编译为原生机器代码——并警告 CPython 字节码漂移使固定硬件变得脆弱。
截至 2026-09-05，RunPyXL 仍处于早期概念验证阶段。runpyxl.com 已上线，包含 GPIO 演示、首页介绍为直接在硬件中运行 Python 的定制芯片，以及常见问题解答，说明展示的所有功能均有效，但生产前缺少关键功能，代码未开源，早期访问（可能是 FPGA 开发板）将提供给留下联系方式的人。材料中未披露产品、资金或法律实体；HN 讨论串中关于内存管理、基准公平性和字节码漂移的开放问题在公开页面上仍未得到解答。
这件事要成立，得有什么
- 具体的第三方关注：HN 项目 43820228 在 2025-04-28 可验证有 983 分和 265 条评论，对硬件概念验证来说是非同寻常的大型发布。
- 赌注明确且可反驳：Python 在硅片中原生执行，没有解释器或即时编译，将在延迟和确定性方面击败嵌入式实时工作的软件运行时。
- 发布是一个论点，而不是营销：一个可复现的 480ns 测量，与指定的现有产品比较，常见问题解答承认项目是早期概念验证。
- HN 讨论串对论点进行了压力测试——评论者要求更公平的 MicroPython viper 基线，并指出 CPython 字节码漂移，作者用具体的权衡设计进行了回答。
可借鉴之处
一个干净、可复现的测量可以引发硬件赌注——但要针对最强的基线进行基准测试，因为 HN 发现了 MicroPython 的 viper，30 倍宣称被削弱。
后续进展
截至 2026-09-05，RunPyXL 仍处于早期概念验证阶段。runpyxl.com 已上线，包含 GPIO 演示、首页介绍为直接在硬件中运行 Python 的定制芯片，以及常见问题解答，说明展示的所有功能均有效，但生产前缺少关键功能，代码未开源，早期访问（可能是 FPGA 开发板）将提供给留下联系方式的人。材料中未披露产品、资金或法律实体；HN 讨论串中关于内存管理、基准公平性和字节码漂移的开放问题在公开页面上仍未得到解答。
资料来源
发现哪里写错了？告诉我们。
轮到你了
你刚读完一家。说说你在做什么，看看谁在赌同一件事。
免费账号 · 3 次免费提问 · 不用绑卡