EN
Back to the archive

The archive · Hardware & Devices · Technical decision · 2025–2026

RunPyXL bets Python belongs in silicon: FPGA demo hits 983 HN points

A solo builder's FPGA processor executes Python directly, no VM/JIT/C; a 480ns GPIO round-trip beat MicroPython ~30x and drew 983 HN points.

RunPyXL

The betThat Python belongs in silicon: a custom processor executes CPython-derived bytecode directly, no VM/JIT/C, so real-time embedded work gets C-like latency in Python.Building

What the business is

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.

How it started

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.

What happened

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.

No ending yet — it is still running.

Background

RunPyXL is a proof-of-concept custom processor that executes Python directly in hardware: no VM, interpreter, JIT, OS or C. A Python toolchain compiles a .py file into CPython bytecode, translates it into a custom assembly (PySM), and produces a binary that runs on a pipelined processor built from scratch and prototyped on a Zynq-7000 FPGA (Arty-Z7-20) at 100MHz; the ARM CPU only handles setup and memory while the Python code itself runs entirely in the hardware core.

The bet is that Python semantics belong in silicon: conventional CPUs are tuned for static, register-based C/C++, while Python's stack-based, dynamic execution wastes cycles on interpreter overhead and runtime typing. The builder wrote the whole stack himself — a Verilog processor with a custom stack-based ISA (PySM) plus a Python toolchain that compiles .py to CPython bytecode, then PySM assembly, then a binary for the Arty-Z7-20 FPGA — and rejected an early RISC-V-extension idea for a clean-slate design so he could rethink Python's execution model.

Posted as a Show HN on 2025-04-28 with one measurement — a 480ns GPIO round-trip versus 14.7µs on a MicroPython PyBoard, ~30x faster — the demo drew 983 points and 265 comments. In-thread he framed the goal as C-like performance with Python's ease, defending his choices: no speculative execution, memory management as the biggest open challenge, ASIC as the eventual goal. Skeptics countered that the benchmark was unfair — MicroPython's viper already compiles hot paths to native machine code — and warned that CPython bytecode drift leaves fixed hardware fragile.

As of 2026-09-05 RunPyXL is still an early proof of concept. runpyxl.com is live with the GPIO demo, a homepage billing it as a custom chip that runs Python directly in hardware, and an FAQ that says everything shown works but key features are missing before production, the code is not open source, and early access — possibly as an FPGA dev board — goes to people who leave contact details. No product, funding or legal entity is disclosed in the material; the HN thread's open questions about memory management, benchmark fairness and bytecode drift remain unanswered on the public pages.

What has to be true

  • Concrete third-party traction: HN item 43820228 is verifiable at 983 points and 265 comments on 2025-04-28, an unusually large launch for a hardware proof of concept.
  • The bet is explicit and falsifiable: Python executed natively in silicon, with no interpreter or JIT, will beat software runtimes on latency and determinism for embedded real-time work.
  • The launch was an argument, not marketing: one reproducible 480ns measurement against a named incumbent, with an FAQ conceding the project is an early proof of concept.
  • The HN thread stress-tests the thesis — commenters demanded a fairer MicroPython viper baseline and flagged CPython bytecode drift, and the author answered with concrete design tradeoffs.

What can be applied

One clean, reproducible measurement can launch a hardware bet — but benchmark against the strongest baseline, because HN found MicroPython's viper and the 30x claim deflated.

Aftermath

As of 2026-09-05 RunPyXL is still an early proof of concept. runpyxl.com is live with the GPIO demo, a homepage billing it as a custom chip that runs Python directly in hardware, and an FAQ that says everything shown works but key features are missing before production, the code is not open source, and early access — possibly as an FPGA dev board — goes to people who leave contact details. No product, funding or legal entity is disclosed in the material; the HN thread's open questions about memory management, benchmark fairness and bytecode drift remain unanswered on the public pages.

Sources

spotted an error? The archive wants to know.

Your turn

You just read one. Describe what you are building, and see who is betting on the same thing.

Free account · 3 free questions · no card

Related cases