12 ms·

Show HN: I built a hardware processor that runs Python

• vrighter 1y ago
  you created a custom processor and made a compiler for it. The source language happens to be python, but the generated bytecode is not what executes eon the cpu. A custom ISA is not the python bytecode
• deleted 1y ago
  [deleted]
• hwpythonner 1y ago
  I built a hardware processor that runs Python programs directly, without a traditional VM or interpreter. Early benchmark: GPIO round-trip in 480ns — 30x faster than MicroPython on a Pyboard (at a lower clock). Demo: https://runpyxl.com/gpio https://runpyxl.com/gpio
• gadys 1y ago
  Look impressive How does this compare to pypy?
  • nurettin 1y ago
    this project takes bytecode, maps it to fpga instructions. pypy can't do that.
  • hwpythonner 1y ago
    PyPy is a JIT compiler — it runs on a standard CPU and accelerates "hot" parts of a program after runtime analysis. This is a great approach for many applications, but it doesn’t fit all use cases. PyXL is a hardware solution — a custom processor designed specifically to run Python programs directly. It's currently focused on embedded and real-time environments where JIT compilation isn't a viable option due to memory constraints, strict timing requirements, and the need for deterministic behavior.
    • wiesbadener 1y ago
      That a interesting project! I have some follow up: > No VM, No C, No JIT. Just PyXL. Is the main goal to achive C-like performance with the ease of writing python? Do you have a perfomance comparision against C? Is the main challenge the memory management? > PyXL runs on a Zynq-7000 FPGA (Arty-Z7-20 dev board). The PyXL core runs at 100MHz. The ARM CPU on the board handles setup and memory, but the Python code itself is executed entirely in hardware. The toolchain is written in Python and runs on a standard development machine using unmodified CPython. > PyXL skips all of that. The Python bytecode is executed directly in hardware, and GPIO access is physically wired to the processor — no interpreter, no function call, just native hardware execution. Did you write some sort of emulation to enable testing it without the physical Arty board?
      • Symmetry 1y ago
        There are a lot of dimensions to what you could call performance. The FPGA here is only clocked at 100 MHz and there's no way you're going to get the same throughput with it as you would on a conventional processor, especially if you add a JIT to optimize things. What you do get here is very low latency.
      • hwpythonner 1y ago
        Goal: Yes — the main goal is to bring C-like or close-to-C performance to Python code, without sacrificing the ease of writing Python. However, due to the nature of Python itself, I'm not sure how close I can get to native C performance, especially competing with systems (both SW and HW) that were revised and refined for decades. Performance comparison against C: I don't have a formal benchmark directly against C yet. The early GPIO benchmark (480ns toggle) is competitive with hand-written C on ARM microcontrollers — even when running at a lower clock speed. But a full systematic comparison (across different workloads) would definitely be interesting for the future. Main challenge: Yes — memory management is one of the biggest challenges. Dynamic memory allocation and garbage collection are tricky to manage efficiently without breaking real-time guarantees. I have a roadmap for it, but would like to stick to a real use case before moving forward. Software emulation: I am using Icarus (could use Verilator) for RTL simulation if that's what you meant. But hardware behavior (like GPIO timing) still needs to be tested on the real FPGA to capture true performance characteristics.
• rthomas6 1y ago
  * What HDL did you use to design the processor? * Could you share the assembly language of the processor? * What is the benefit of designing the processor and making a Python bytecode compiler for it, vs making a bytecode compiler for an existing processor such as ARM/x86/RISCV?
  • hwpythonner 1y ago
    Thanks for the question. HDL: Verilog Assembly: The processor executes a custom instruction set called PySM (Not very original name, I know :) ). It's inspired by CPython Bytecode — stack-based, dynamically typed — but streamlined to allow efficient hardware pipelining. Right now, I’m not sharing the full ISA publicly yet, but happy to describe the general structure: it includes instructions for stack manipulation, binary operations, comparisons, branching, function calling, and memory access. Why not ARM/X86/etc... Existing CPUs are optimized for static, register-based compiled languages like C/C++. Python’s dynamic nature — stack-based execution, runtime type handling, dynamic dispatch — maps very poorly onto conventional CPUs, resulting in a lot of wasted work (interpreter overhead, dynamic typing penalties, reference counting, poor cache locality, etc.).
    • pak9rabid 1y ago
      Wow, this is fascinating stuff. Just a side question (and please understand I am not a low-level hardware expert, so pardon me if this is a stupid question): does this arch support any sort of speculative execution, and if so do you have any sort of concerns and/or protections in place against the sort of vulnerabilities that seem to come inherent with that?
      • hwpythonner 1y ago
        Thanks — and no worries, that’s a great question! Right now, PyXL runs fully in-order with no speculative execution. This is intentional for a couple of reasons: First, determinism is really important for real-time and embedded systems — avoiding speculative behavior makes timing predictable and eliminates a whole class of side-channel vulnerabilities. Second, PyXL is still at an early stage — the focus right now is on building a clean, efficient architecture that makes sense structurally, without adding complex optimizations like speculation just for the sake of performance. In the future, if there's a clear real-world need, limited forms of prediction could be considered — but always very carefully to avoid breaking predictability or simplicity.
• jrexilius 1y ago
  Amazing work! Is the primary goal here to allow more production use of python in an embedded context, rather than just prototyping?
  • hwpythonner 1y ago
    Thank you! And yes, exactly.
• hermitShell 1y ago
  fantastic project. Do you envision this as living on FPGA's forever, or getting into silicon directly? Maybe an extension of RISC-V?
  • hwpythonner 1y ago
    Oh boy, I definitely considered that — turning PyXL into a RISC-V extension was an early idea I thought of. It could probably be adapted into one. But I ultimately decided to build it as its own clean design because I wanted the flexibility to rethink the entire execution model for Python — not just adapt an existing register-based architecture. FPGA is for prototyping. although this could probably be used as a soft core. But looking forward, ASIC is definitely the way to go.
• froh 1y ago
  Do I get this right? this is an ASIC running a python-specific microcontroller which has python-tailored microcode? and together with that a python bytecode -> microcode compiler plus support infrastructure to get the compiled bytcode to the asic? fun :-) but did I get it right?
  • hwpythonner 1y ago
    You're close: It's currently running on an FPGA (Zynq-7000) — not ASIC yet — but yeah, could be transferable to ASIC (not cheap though :)) It's a custom stack-based hardware processor tailored for executing Python programs directly. Instead of traditional microcode, it uses a Python-specific instruction set (PySM) that hardware executes. The toolchain compiles Python → CPython Bytecode → PySM Assembly → hardware binary.
    • cchianel 1y ago
      As someone who did a CPython Bytecode → Java bytecode translator (https://timefold.ai/blog/java-vs-python-speed https://timefold.ai/blog/java-vs-python-speed), I strongly recommend against the CPython Bytecode → PySM Assembly step: - CPython Bytecode is far from stable; it changes every version, sometimes changing the behaviour of existing bytecodes. As a result, you are pinned to a specific version of Python unless you make multiple translators. - CPython Bytecode is poorly documented, with some descriptions being misleading/incorrect. - CPython Bytecode requires restoring the stack on exception, since it keeps a loop iterator on the stack instead of in a local variable. I recommend instead doing CPython AST → PySM Assembly. CPython AST is significantly more stable.
      • nurettin 1y ago
        This was my first thought as well. They will be stuck at a certain python version
      • hwpythonner 1y ago
        Thanks — really appreciate your insights. You're absolutely right that CPython bytecode changes over time and isn’t perfectly documented — I’ve also had to read the CPython source directly at times because of unclear docs. That said, I intentionally chose to target bytecode instead of AST at this stage. Adhering to the AST would actually make me more vulnerable to changes in the Python language itself (new syntax, new constructs), whereas bytecode changes are usually contained to VM-level behavior. It also made it much easier early on, because the PyXL compiler behaves more like a simple transpiler — taking known bytecode and mapping it directly to PySM instructions — which made validation and iteration faster. Either way, some adaptation will always be needed when Python evolves — but my goal is to eventually get to a point where only the compiler (the software part of PyXL) needs updates, while keeping the hardware stable.
• freeone3000 1y ago
  This is amazing! Is the “microcode” compiled to final native on the host or the coprocessor? I’m guessing due to the lack of JIT, it’s executed on the host?
  • hwpythonner 1y ago
    The microcode or the ISA of the system actually runs on the co-processor (PyXL custom cpu) If you refer to the ARM part as the host (did you?) it's just orchestrating the whole thing, it doesn't run the actual Python program
• Jean-Papoulos 1y ago
  >PyXL is a custom hardware processor that executes Python directly — no interpreter, no JIT, and no tricks. It takes regular Python code and runs it in silicon. So, no using C libraries. That takes out a huge chunck of pip packages...
  • hwpythonner 1y ago
    You're absolutely right — today, PyXL only supports pure Python execution, so C extensions aren’t directly usable. That said, in future designs, PyXL could work in tandem with a traditional CPU core (like ARM or RISC-V), where C libraries execute on the CPU side and interact with PyXL for control flow and Python-level logic. There’s also a longer-term possibility of compiling C directly to PyXL’s instruction set by building an LLVM backend — allowing even tighter integration without a second CPU. Right now the focus is on making native Python execution viable and efficient for real-time and embedded systems, but I definitely see broader hybrid models ahead.
• HPsquared 1y ago
  Not to be confused with openpyxl, a library for working with Excel files. That then makes me wonder if someone could implement Excel in hardware! (Or something like it)
  • hwpythonner 1y ago
    I just had to give it a name. Didn't really search for vacancies. Maybe I need to rename :)
• obitsten 1y ago
  Why is it not routine to "compile" Python? I understand that the interpreter is great for rapid iteration, cross compatibility, etc. But why is it accepted practice in the Python world to eschew all of the benefits of compilation by just dumping the "source" file in production?
  • franga2000 1y ago
    There's no benefit that I know of, besides maybe a tiny cold start boost (since the interpreter doesn't need to generate the bytecode first). I have seen people do that for closed-source software that is distributed to end-users, because it makes reverse engineering and modding (a bit) more complicated.
  • hwpythonner 1y ago
    There have been efforts (like Cython, Nuitka, PyPy’s JIT) to accelerate Python by compiling subsets or tracing execution — but none fully replace the standard dynamic model at least as far as I know.
  • Someone 1y ago
    Python doesn’t eschew all benefits of compilation. It is compiled, but to an intermediate byte code, not to native code, (somewhat) similar to the way java and C# compile to byte code. Those, at runtime (and, nowadays, optionally also at compile time), convert that to native code. Python doesn’t; it runs a bytecode interpreter. Reason Python doesn’t do that is a mix of lack of engineering resources, desire to keep the implementation fairly simple, and the requirement of backwards compatibility of C code calling into Python to manipulate Python objects.
  • cchianel 1y ago
    The primary reason, in my opinion, is the vast majority of Python libraries lack type annotations (this includes the standard library). Without type annotations, there is very little for a non-JIT compiler to optimize, since: - The vast majority of code generation would have to be dynamic dispatches, which would not be too different from CPython's bytecode. - Types are dynamic; the methods on a type can change at runtime due to monkey patching. As a result, the compiler must be able to "recompile" a type at runtime (and thus, you cannot ship optimized target files). - There are multiple ways every single operation in Python might be called; for instance `a.b` either does a __dict__ lookup or a descriptor lookup, and you don't know which method is used unless you know the type (and if that type is monkeypatched, then the method that called might change). A JIT compiler might be able to optimize some of these cases (observing what is the actual type used), but a JIT compiler can use the source file/be included in the CPython interpreter.
• davidkwast 1y ago
  Wow. Congratz
  • hwpythonner 1y ago
    Thank you!
• swoorup 1y ago
  How does garbage collection work here? Are they just set of PySM code?
  • hwpythonner 1y ago
    GC is still a WIP, but the key idea is the system won't stall — garbage collection happens asynchronously, in the background, without interrupting PyXL execution.
    • jy14898 1y ago
      Sounds similar to something one of my classmates worked on at uni https://www.bristol.ac.uk/research/groups/trustworthy-systems-laboratory/research/innovative-hardware-design/ihgc/ https://www.bristol.ac.uk/research/groups/trustworthy-system...
• wodenokoto 1y ago
  I can totally see a future where you can select “accelerated python” as an option for your AWS lambda code.
  • hwpythonner 1y ago
    When I first started PyXL, this kind of vision was exactly on my mind. Maybe not AWS Lambda specifically, but definitely server-side acceleration — especially for machine learning feature generation, backend control logic, and anywhere pure Python becomes a bottleneck. It could definitely get there — but it would require building a full-scale deployment model and much broader library and dynamic feature support. That said, the underlying potential is absolutely there.
    • petra 1y ago
      This sounds brilliant. What's missing so you could create a demo for vc's or the relevant companies , proving the potential of this as competitive server-class core ?
      • hwpythonner 1y ago
        Good question! PyXL today is aimed more at embedded and real-time systems. For server-class use, I'd need to mature heap management, add basic concurrency, a simple network stack, and gather real-world benchmarks (like requests/sec). That said, I wouldn’t try to fully replicate CPython for servers — that's a very competitive space with a huge surface area. I'd rather focus on specific use cases where deterministic, low-latency Python execution could offer a real advantage — like real-time data preprocessing or lightweight event-driven backends. When I originally started this project, I was actually thinking about machine learning feature generation workloads — pure Python code (branches, loops, dynamic types) without heavy SIMD needs. PyXL is very well suited for that kind of structured, control-flow-heavy workload. If I wanted to pitch PyXL to VCs, I wouldn’t aim for general-purpose servers right away. I'd first find a specific, focused use case where PyXL's strengths matter, and iterate on that to prove value before expanding more broadly.
• tuetuopay 1y ago
  So basically you took the idea of Jazelle extensions that can run Java bytecode natively, but for python? This is amazing, great work!
  • hwpythonner 1y ago
    Thanks you very much. I learned of Jazelle after started working on it and this is a good thing, because Jazelle didn't become too popular AFAIK, so it would just make me quit. Glad I didn't though :)
    • mid-kid 1y ago
      The significant difference between Jazelle and your project is how Jazelle sits on top of a CPU that can already run a java interpreter without the instruction set extensions, said instruction set didn't implement all of java (it still required a runtime to implement the missing opcodes, in ARM), and java runtimes quickly got better optimized than doing the same thing with the instruction set. I think building a CPU that can only do this is a really novel idea and am really interested in seeing when you eventually disclose more implementation details. My only complaint is that it isn't Lua :P
• Y_Y 1y ago
  Are there any limitations on what code can run? (discounting e.g. memory limitations and OS interaction) I'd love to read about the design process. I think the idea of taking bytecode aimed at the runtime of dynamic languages like Python or Ruby or even Lisp or Java and making custom processors for that is awesome and (recently) under-explored. I'd be very interested to know why you chose to stay this, why it was a good idea, and how you went about the implementation (in broad strokes if necessary).
  • hwpythonner 1y ago
    Thanks — really appreciate the interest! There are definitely some limitations beyond just memory or OS interaction. Right now, PyXL supports a subset of real Python. Many features from CPython are not implemented yet — this early version is mainly to show that it's possible to run Python efficiently in hardware. I'd prefer to move forward based on clear use cases, rather than trying to reimplement everything blindly. Also, some features (like heavy runtime reflection, dynamic loading, etc.) would probably never be supported, at least not in the traditional way, because the focus is on embedded and real-time applications. As for the design process — I’d love to share more! I'm a bit overwhelmed at the moment preparing for PyCon, but I plan to post a more detailed blog post about the design and philosophy on my website after the conference.
    • mikepurvis 1y ago
      In terms of a feature-set to target, would it make sense to be going after RPython instead of "real" Python? Doing that would let you leverage all the work that PyPy has done on separating what are the essential primitives required to make a Python vs what are the sugar and abstractions that make it familiar: https://doc.pypy.org/en/latest/faq.html#what-is-pypy https://doc.pypy.org/en/latest/faq.html#what-is-pypy
    • ammar2 1y ago
      > I'd prefer to move forward based on clear use cases Taking the concrete example of the `struct` module as a use-case, I'm curious if you have a plan for it and similar modules. The tricky part of course is that it is implemented in C. Would you have to rewrite those stdlib modules in pure python?
• flmontpetit 1y ago
  For a minute there I was imagining Python as the actual instruction set and my brain was segfaulting. Very cool project still
• TickleSteve 1y ago
  There is a long history of CPUs tailored to specific languages: - Lisp/lispm - Ada/iAPX - C/ARM - Java/Jazelle Most don't really take off or go in different directions as the language goes out of fashion.
  • Symmetry 1y ago
    Also a fairly interesting Haskell efforts. https://mn416.github.io/reduceron-project/ https://mn416.github.io/reduceron-project/ These range from a few instructions to accelerate certain operations, to marking memory for the garbage collector, to much deeper efforts.
  • jonathaneunice 1y ago
    Also: UCSD p-System, Symbolics Lisp-on-custom hardware, ... Historically their performance is underwhelming. Sometimes competitive on the first iteration, sometimes just mid. But generally they can't iterate quickly (insufficient resources, insufficient product demand) so they are quickly eclipsed by pure software implementations atop COTS hardware. This particular Valley of Disappointment is so routine as to make "let's implement this in hardware!" an evergreen tarpit idea. There are a few stunning exceptions like GPU offload—but they are unicorns.
    • noosphr 1y ago
      They were a tar pit in the 1980s and 1990s when Moores law meant a 16x increase in processor speed every 6 years. Right now the only reason why we don't have new generations of these eating the lunch of general purpose CPUs is that you'd need to organize a few billion transistors into something useful. That's something a bit beyond what just about everyone (including Intel now apparently) can manage.
      • jonathaneunice 1y ago
        Sure. The need to organize millions (now 10s to 100s of billions) of transistors to do something useful, the economics and will to bring those to market, the need to coordinate functions baked into hardware with the faster moving and vastly more-plastic software world—oh, and Amdahl's Law. They are the tar pit. Transistor counts skyrocket, but the principles and obstacles have not changed one iota in over 50 years.
• igtztorrero 1y ago
  Amazing,
• igtztorrero 1y ago
  Amazing, I'm sure many programmers would join to contribute to your great project, which could become as big as a Python-based operating system, which due to the simplicity of the code would advance very quickly.
  • hwpythonner 1y ago
    Thank you! Right now I'm focusing on keeping the core simple, efficient, and purpose-driven — mainly to run Python well on hardware for embedded and real-time use cases. As for the future, I’m keeping an open mind. It would be exciting if it grew into something bigger, but my main focus for now is making sure the foundation is as solid and clean as possible.
• willvarfar 1y ago
  Fantastic work! :D Must be super-satisfying to get it up and running! :D Is it tied to a particular version of python?
  • hwpythonner 1y ago
    Thanks — it’s definitely been incredibly satisfying to see it run on real hardware! Right now, PyXL is tied fairly closely to a specific CPython version's bytecode format (I'm targeting CPython 3.11 at the moment). That said, the toolchain handles translation from Python source → CPython bytecode → PyXL Assembly → hardware binary, so in principle adapting to a new Python version would mainly involve adjusting the frontend — not reworking the hardware itself. Longer term, the goal is to stabilize a consistent subset of Python behavior, so version drift becomes less painful.
• hoseja 1y ago
  I wonder if silicon can feel pain.
• boxed 1y ago
  How big a deal would it be to include the bytecode->PySM translation into the ISA? It seems like it would be even cooler if the CPU actually ran python bytecode itself.
  • hwpythonner 1y ago
    That's a great question! I actually thought a lot about that early on. In theory, you could build a CPU that directly interprets Python bytecode — but Python bytecode is quite high-level and irregular compared to typical CPU instructions. It would add a lot of complexity and make pipelining much harder, which would hurt performance, especially for real-time or embedded use. By compiling the Python bytecode ahead of time into a simpler, stack-based ISA (what I call PySM), the CPU can stay clean, highly pipelined, and efficient. It also opens the door in the future to potentially supporting other languages that could target the same ISA!
• bieganski 1y ago
  it would be nice to have some peripheral drivers implemented (UART, eMMC etc). having this, the next tempting step is to make `print` function work, then the filesystem wrapper etc. btw - what i'm missing is a clear information of limitations. it's definitely not true that i can take any Python snippet and run it using PyXL (for example threads i suppose?)
  • hwpythonner 1y ago
    Great points! Peripheral drivers (like UART, SPI, etc.) are definitely on the roadmap - They'd obviously be implemented in HW. You're absolutely right — once you have basic IO, you can make things like print() and filesystem access feel natural. Regarding limitations: you're right again. PyXL currently focuses on running a subset of real Python — just enough to show it's real python and to prove the core concept, while keeping the system small and efficient for hardware execution. I'm intentionally holding off on implementing higher-level features until there's a real use case, because embedded needs can vary a lot, and I want to keep the system tight and purpose-driven. Also, some features (like threads, heavy runtime reflection, etc.) will likely never be supported — at least not in the traditional way — because PyXL is fundamentally aimed at embedded and real-time applications, where simplicity and determinism matter most.
    • throwup238 1y ago
      Are you planning on licensing the IP core? It would be great to have your core integrated with ESP32, running alongside their other architectures, so they can handle the peripheral integration, wifi, and Python code loading into your core, while it sits as another master on the same bus as the other peripherals. Do you plan to have AMBA or Wishbone Bus support?
      • hwpythonner 1y ago
        Thanks — yes, licensing is something I'm open to exploring in the future. PyXL already communicates with the ARM side over AXI today (Zynq platform).
• thenobsta 1y ago
  Amazing work! This is a great project! Every time I see a project that has a great implementation on an FPGA, I lament the fact that Tabula didn’t make it, a truly innovative and fast FPGA. <https://en.m.wikipedia.org/wiki/Tabula,_Inc. https://en.m.wikipedia.org/wiki/Tabula,_Inc.>
• IlikeKitties 1y ago
  Is this running on an FPGA or were you able to fab a custom chip?
  • hwpythonner 1y ago
    Just running on FPGA at the moment. This is still an early-stage project — it's not completed yet, and fabricating a custom chip would involve huge costs. I'm a solo developer worked on this in my spare time, so FPGA was the most practical way to prove the core concepts and validate the architecture. Longer term, I definitely see ASIC fabrication as the way to unlock PyXL’s full potential — but only once the use case is clear and the design is a little more mature.
    • throwawaymaths 1y ago
      there are several free asic shuttle runs available for hobbyists iirc
    • jamesfmilne 1y ago
      Could be a candidate for Tiny Tapeout in the future. https://tinytapeout.com https://tinytapeout.com
      • deleted 1y ago
        [deleted]
    • IlikeKitties 1y ago
      Oh, my comment wasn't meant as a criticism just curiosity because I would have been extremely surprised to see such a project being fabricated. I find the idea of a processor designed for a specific very high level language quite interesting. What made you choose python and do you think it's the "correct" language for such a project? It sure seems convenient as a language but I wouldn't have thought it is best suited for that task due to the very dynamic nature of it. Perhaps something like Nim which is similar but a little less dynamic would be a better choice?
    • ActorNightly 1y ago
• pjmlp 1y ago
  This is kind of cool, basically a Python Machine. :)
  • boutell 1y ago
    I see what you did there! There's a LISP Machine with its guts on display at the MIT Museum. I recall we had one in the graduate student comp sci lab at University of Delaware (I was a tolerated undergrad). By then LISP was faster on a Sun workstation, but someone had taught it to play Tetris.
• zoobab 1y ago
  To reflash ch32v003 chips, I need to create bits of 250ns, so with 480ns it's not enough. Is there a way to make it faster?
• tgtweak 1y ago
  Have you tested it on any faster FPGAs? I think Azure has instances with xilinx/AMD accelerators paired. >Standard_NP10s instance, 1x AMD Alveo U250 FPGA (64GB) Would be curious to see how this benchmarks on a faster FGPA since I imagine clock frequency is the latency dictator - while memory and tile can determine how many instances can run in parallel.
  • hwpythonner 1y ago
    Not yet — I'm currently testing on a Zynq-7000 platform (embedded-class FPGA), mainly because it has an ARM CPU tightly integrated (and it's rather cheap). I use the ARM side to handle IO and orchestration, which let me focus the FPGA fabric purely on the Python execution core, without having to build all the peripherals from scratch at this stage. To run PyXL on a server-class FPGA (like Azure instances), some adaptations would be needed — the system would need to repurpose the host CPU to act as the orchestrator, handling memory, IO, etc. The question is: what's the actual use case of running on a server? Besides testing max frequency -- for which I could just run Vivado on a different target (would need license for it though) For now, I'm focusing on validating the core architecture, not just chasing raw clock speeds.
    • zoobab 1y ago
      You can get cheap Zynq boards on Aliexpress, like old mining boards. I have a Paralella board here with a Zynq.
• boutell 1y ago
  This is very, very cool. Impressive work. I'm interested to see whether the final feature set will be larger than what you'd get by creating a type-safe language with a pythonic syntax and compiling that to native, rather than building custom hardware. The background garbage collection thing is easier said than done, but I'm talking to someone who has already done something impressively difficult, so...
  • rangerelf 1y ago
    > I'm interested to see whether the final feature set will be larger than what you'd get by creating a type-safe language with a pythonic syntax and compiling that to native, rather than building custom hardware. It almost sounds like you're asking for Nim ( https://nim-lang.org/ https://nim-lang.org/ ); and there are some projects using it for microcontroller programming, since it compiles down to C (for ESP32, last I saw).
• dec0dedab0de 1y ago
  Congratulations! This is so cool, I have dreamt about doing this but wouldn't know where to start. Do you have a plan for releasing it? What is your background? Was there anything that was way more difficult than you thought it would be? Or anything that was easier than you expected?
  • hwpythonner 1y ago
    Thanks so much — really appreciate it! Right now, the plan is to present it at PyCon first (next month) and then publish more about the internals afterward. Long-term, I'm keeping an open mind, not sure yet. My background is in high-frequency trading (HFT), high-performance computing (HPC), systems programming, and networking. I didn't come from HW background — or at least, I wasn't when I started — but coming from the software side gave me a different perspective on how dynamic languages could be made much more efficient at the hardware level. Difficult - adapting the Python execution model to my needs in a way that keeps it self-coherent if it makes sense. This is still fluid and not finalized... Easy - Not sure if categorize as easy, but more surprising: The current implementation is rather simple and elegant (at least I think so :-) ), so still no special advanced CPU design stuff (branch prediction, super-scalar, etc). So even now, I'm getting a huge improvement over CPython or MicroPython VMs in the known python bottlenecks (branchings, function calls, etc)
    • dec0dedab0de 1y ago
      Difficult - adapting the Python execution model to my needs in a way that keeps it self-coherent if it makes sense. This is still fluid and not finalized... Alright well those dots are begging me to ask what they mean, or at least one specific story for the nerds :-) Long-term, I'm keeping an open mind, not sure yet. Well please consider open source, even if you charge for access to your open source code. And even if you don't go open source, atleast make it cheap enough that a solo developer could afford to build on it without thinking.
• jimbokun 1y ago
  What's your development background that prepared you to take on a project like this? Clearly you know a lot about both low level Python internals and a fair amount about hardware design to pull this off.
  • hwpythonner 1y ago
    I'm a software engineer by background, mostly in high-frequency trading (HFT), HPC, systems programming, and networking — so a lot of focus on efficiency and low-level behavior. I had played a bit with FPGAs before, but nothing close to this scale — most of the hardware and Python internals work I had to figure out along the way.
• actinium226 1y ago
  This is awesome
• UncleOxidant 1y ago
  Is the source code available?
  • hwpythonner 1y ago
    The source isn’t public at this stage. I'm still deciding the best path forward after PyCon.
• two_handfuls 1y ago
  This is a one-person project? I'm impressed!
  • hwpythonner 1y ago
    Thanks so much — really appreciate it! Yes, it's been a one-person project so far — just a lot of spare time, persistence, and iteration.
• ConanRus 1y ago
  > the program is compiled to a CPython Bytecode and then compiled again to PyXL assembly. It is then linked together and a binary is generated. why are we not doing this for a standard python? i think LLVM is just for that, no?
• sneak 1y ago
  How long did you work on this?
• yanniszark 1y ago
  Great work! :D I had a question about that though. Instead of compiling to PySM, why not compile directly to a real assembly like ARM? Is the PySM assembly very special to accomodate python features in a way that can't be done efficiently in existing architectures like ARM?
  • hwpythonner 1y ago
    Thanks — appreciate it! Good question. In theory, you can compile anything Turing-complete to anything else — ARM and Python are both Turing-complete. But practically, Python's model (dynamic typing, deep use of the stack) doesn't map cleanly onto ARM's register-based, statically-typed instruction set. PySM is designed to match Python’s structure much more naturally — it keeps the system efficient, simpler to pipeline, and avoids needing lots of extra translation layers.
• fluorinerocket 1y ago
  Makes me think of LabVIEW FPGA, where you could run LabVIEW code directly on FPGA, more like generate vhdl or verilog from LabVIEW, and do very high loop rate deterministic control systems. Very cool. Except with that you were locked down to the national instruments ecosystem and no one really used it. I
• jollyllama 1y ago
  Name's a bit confusing when XLWings exists
  • dragonwriter 1y ago
    > Name's a bit confusing when XLWings exists How? XLWings is not a similar name to pyxl. However, even so, the name is... Heavily overloaded: https://pyxl.com/ https://pyxl.com/ (some kind of strategy/CRM/AI thing) https://pyxl.ai/ https://pyxl.ai/ (AI website builder) https://www.pyxl.pro/ https://www.pyxl.pro/ (AI image generator) https://github.com/dropbox/pyxl https://github.com/dropbox/pyxl (Inline HTML extension for Python) https://openpyxl.readthedocs.io/en/stable/ https://openpyxl.readthedocs.io/en/stable/ (A Python library to read/write Excel files) https://www.pyxll.com/ https://www.pyxll.com/ (Excel Add-in to support add-ins written in Python)
    • jollyllama 1y ago
      >has XL >has to do with Python Indeed, the namespace is rather crowded.
• redox99 1y ago
  What's the logic behind going for stack based?
  • hwpythonner 1y ago
    Python’s execution model is already very stack-oriented — CPython bytecode operates by pushing and popping values almost constantly. Building PyXL as a stack machine made it much more natural to map Python semantics directly onto hardware, without forcing an unnatural register-based structure on it. It also avoids a lot of register allocation overhead (renaming and such).
  • bhasi 1y ago
    What other models are there? Would love to learn about them.
    • redox99 1y ago
      Your typical PC is register based.
• rkagerer 1y ago
  Back when C# came out, I thought for sure someone would make a processor that would natively execute .Net bytecode. Glad to see it finally happened for some language.
  • jiehong 1y ago
    Java got that with smart cards for example. Cute oddities of the past
    • monocasa 1y ago
      JavaCard was just implemented as just a regular interpreter last time I checked.
  • whoomp12342 1y ago
    I'd be surprised if azure app services didn't do this already.
    • actionfromafar 1y ago
      Wouldn't that be a real scoop?
    • john-h-k 1y ago
      I’d be willing to bet my net worth that they don’t
      • whoomp12342 1y ago
        then why does azure app services have you pick the .net version?!
        • john-h-k 1y ago
          I can't tell if this is joke but will assume not. It's because the .net version is needed for some reason. There are not processors that run .net bytecode, primarily because they would be slower and worse (and again, don't exist)
• jay-barronville 1y ago
  This type of project is why I love HN. This work is brilliant! Almost every question I had, you already answered in the comments. The only one remaining at the moment: How long exactly have you been working on PyXL?
• nynx 1y ago
  This is cool for sure. I think you’ll ultimately find that this can’t really be faster than modern OoO cores because python instructions are so complex. To execute them OoO or even at a reasonable frequency (e.g. to reduce combinatorial latency), you’ll need to emit type-specialized microcode on the fly, but you can’t do that until the types are known — which is only the case once all the inputs are known for python.
  • gavinsyancey 1y ago
    Sure, but for embedded use cases (which this is targeting), the goal isn't raw speed so much as being fast enough for specific use cases while minimizing power usage / die area / cost.
  • hwpythonner 1y ago
    Thanks — appreciate it! You're right that dynamic typing makes high-frequency execution tricky, and modern OoO cores are incredibly good at hiding latencies. But PyXL isn't trying to replace general-purpose CPUs — it's designed for efficient, predictable execution in embedded and real-time systems, where simplicity and determinism matter more than absolute throughput. Most embedded cores (like ARM Cortex-M and simple RISC-V) are in-order too — and deliver huge value by focusing on predictability and power efficiency. That said, there’s room for smart optimizations even in a simple core — like limited lookahead on types, hazard detection, and other techniques to smooth execution paths. I think embedded and real-time represent the purest core of the architecture — and once that's solid, there's a lot of room to iterate upward for higher-end acceleration later.
    • IshKebab 1y ago
      Very cool! Nobody who really wants simplicity and determinism is going to be using Python on a microcontroller though.
      • actionfromafar 1y ago
        Hm, why not though. People managed to do it with tiny JVMs before, so why not a Python variant.
• _JamesA_ 1y ago
  It would be interesting to see something like this that runs WASM as a universal bytecode.
  • IshKebab 1y ago
    I'm sure it's been done. I doubt it really is any better though because you can do a lot of optimisations in software that you can't do in hardware.
• bluelightning2k 1y ago
  I am a pretty smart person. But once in a while I see something like this which reminds me there's always someone far smarter. Absolutely incredible.
• yeahwhatever10 1y ago
  How are you simulating the designs for the FPGA? Are you paying for ModelSim?
  • hwpythonner 1y ago
    No, I'm not paying for ModelSim. I've been using free tools like Icarus Verilog — it was good enough for my needs so far. If I need more performance later, I might migrate to Verilator. I could also use Vivado’s built-in XSim, but coming from a software background, I generally prefer more Unix-style tools rather than heavier hardware IDEs.
• echoangle 1y ago
  Would this be able to handle an exec()- or eval()-call? Is there a Python byte code compiler available as python byte code to include in this processor?
  • IshKebab 1y ago
    Yeah this is surely a subset of Python.
• startupsfail 1y ago
  Nice, next step could be rolling out that bytecode compiler in Python, so it’s self-contained. And a port to some LLM-on-silicon, so we could have it executing Python as the inference goes :-P
• actinium226 1y ago
  So first of all, this is awesome and props to you for some great work. I have what may be a dumb question, but I've heard that Lua can be used in embedded contexts, and that it can be used without dynamic memory allocation and other such things you don't want in real time systems. How does this project compare to that? And like I said it's likely a dumb question because I haven't actually used Lua in an embedded context but I imagine if there's something there you've probably looked at it?
  • woodrowbarlow 1y ago
    with embedded scripting languages (including lua and micropython) the CPU is running a compiled interpreter (usually written in C, compiled to the CPU's native architecture) and the interpreter is running the script. on PyXL, the CPU's native architecture is python bytecode, so there's no compiled interpreter.
• warble 1y ago
  Wow, these FPGAs are not cheap. Don't they also have a couple of ARM cores attached on the SOC?
• simonw 1y ago
  This looks incredible. Do you have any open source code available for this yet? Are you planning to release this as open source? If not, do you have a rough idea for how you plan to commercial license this tech?
• M4R5H4LL 1y ago
  I love this kind of project, this is wonderful work. I guess the challenge is to now make it work for general purpose Python. In any case it looks very much like a marketable product already. I would seek financing to see how far this can go.
• JadoJodo 1y ago
  I'd like to invite any Python devs to go on a tangent with me: Can you give me the scoop on Python, the language? I see things like this project, and it seems very impressive, but being an outsider to the language, I don't "get" it. More specifically: I'm curious to hear thoughts on a) what made this difficult prior to now (with Python), b) why Python is useful for this, and c) what are your thoughts on Python itself? To add some more context: I know a lot of developers who work with Python (Flask); Some love it, some hate it (as with any language). My experience has been mainly via homelab/OSS tools that all seem to embrace the language. And yet while the language itself seems very straight forward and easy to use, my experience with the Python _ecosystem_ (again, as an outsider) has been... difficult. Python 2 vs 3, virtual environments, libraries for each version, etc. It feels as though anytime I've had to use it outside a pre-built Docker container, these issues result in throwing spaghetti at the wall trying to figure out how to even get it working at all. As a PHP/Go dev, it's one of the languages for which I could see myself having a real interest, but this has so far made me hesitant (and I don't want to be).
  • whatnow37373 1y ago
    Old-timer here, used Python for about ten years professionally (Go now). c) It’s a monstrous dumpster fire and getting worse over time, but so is everything else (in the same space). I like Go, but I can see how it’s not for everyone.
  • PaulHoule 1y ago
    My impression was that if you had a problem with Python and then added Docker now you have two problems. I worked at one place where the data sci's had an amazing ability to find defective Pythons. Python is going in the right directions in terms of all the deployability and big issues but it should have been where it is now 7 years ago. Specifically, I sketched out a system that worked like uv but was written in pure Python, I didn't start on it for two reasons: (a) the bootstrapping problem that I couldn't ever stop devs from trashing the Python that it runs in, and (b) from lots of trying it didn't seem possible to convince most Pythoners that pip was broken or that it mattered... uv solved (a) by removing Python from the bootstrap and (b) by being crazy fast.
  • 1y ago
• kristianpaul 1y ago
  This always mede think back to J1 Forth CPU https://excamera.com/files/j1.pdf https://excamera.com/files/j1.pdf
• brap 1y ago
  Up next: a processor that will directly execute your prompt
  • growthwtf 1y ago
    genuinely not a bad idea
• crest 1y ago
  A "480ns GPIO roundtrip" @ 100MHz implies 48 cycles for a single GPIO access. I would understand one or two cycles, but what does it spend the other ~46 cycles on? Does Python really have a >40x overhead compared to assembler or C even on optimised hardware or is the benchmark code that bad?
  • hwpythonner 1y ago
    Great question! You're right that it can definitely be faster — there's real room for optimization. When I have time, I may write a blog post that will explain where the cycles go, why it's different from raw assembler toggling, and how it could be improved. Also, just to keep things in perspective — don't forget to compare apples to apples: On a Pyboard running MicroPython, a simple GPIO roundtrip takes about 14 microseconds. PyXL is already achieving 480 nanoseconds, so it’s a very different baseline. Thanks for raising it — it's a very good point.
• dcreater 1y ago
  Very impressive! Can it run on RISC V?
  • SpaceNoodled 1y ago
    This is a unique architecture, not just software.
    • dcreater 1y ago
      Sorry then Im not following how this can be useful if I cant use off the shelf hardware?
      • lizknope 1y ago
        It does. OP says it runs on an FPGA, specifically a Zynq-7000
• rangerelf 1y ago
  Incredible work :-) Congratulations!!
  • hwpythonner 1y ago
    Thank you!
• focusgroup0 1y ago
  Incredible work. This is a paradigm shift for ML and embedded workflows. And congratulations, you are going to ring the bell with this one.
  • hwpythonner 1y ago
    Thank you so much — that really means a lot! It's still early days and there’s a lot more work ahead, but I'm very excited about the possibilities. I definitely see areas like embedded ML and TinyML as a natural fit — Python execution on low-power devices opens up a lot of doors that weren't practical before.
• ingen0s 1y ago
  Thats great!
• sunray2 1y ago
  Very interesting! What's the fundamental physical limits here? Namely, timing precision, latency and jitter? How fast could PyXL bytecode react to an input? For info, there is ARTIQ: vaguely similar thing that effectively executes Python code with 'embedded level' performance: https://m-labs.hk/experiment-control/artiq/ https://m-labs.hk/experiment-control/artiq/ ARTIQ is quite common in quantum physics labs. For that you need very precise and determining timing. Imagine you're interfering two photons as they reach a piece of glass, so that they can interact. It doesn't get faster than photons! That typically means nanosecond timing, sub-microsecond latency. How ARTIQ does it is also interesting. The Python code is separate from the FPGA which actually executes the logic you want to do. In a hand-wavy way, you're then 'as fast' as the FPGA. How, though? The catch is, you have to get the Python code and FPGA gateware talking to each other, and that's technically difficult and has many gotchas. In comparison, although PyXL isn't as performant, if it makes it simpler for the user, that's a huge win for everyone. Congrats once again!
  • sunray2 1y ago
    (minor edit: for observing experimental signatures of photon interference, nanosecond precision is the minimum to see anything when synchronising your experimental bits and pieces, but to see a useful signal needs precision at the 10s of picoseconds! So, beyond what's immediately possible here.)
    • brcmthrowaway 1y ago
      Did you work at Rigetti?
      • sunray2 1y ago
        No, didn't work there. I looked up any connection to ARTIQ they may have: it seems they do full stack QC, as they have their own quantum compiler [1]. But I'm not really sure what they're doing currently. [1] https://github.com/quil-lang/quilc https://github.com/quil-lang/quilc
• globalnode 1y ago
  Great idea and frankly I'm surprised it hasn't been done before. Probably because you would have to sell an awful lot of them to make $. But there would definitely be a market I think. For example if they were cheap, say much cheaper than a Pi, I'd go for something like this over a full Linux machine for dedicated projects. But then how would you do complex things like interfacing to cameras and leveraging encoders etc? Or is this sort of device just not for that type of project.
• zik 1y ago
  This is a very cool project but I feel like the claim is overstated: "PyXL is a custom hardware processor that executes Python directly — no interpreter, no JIT, and no tricks. It takes regular Python code and runs it in silicon." Reading further down the page it says you have to compile the python code using CPython, then generate binary code for its custom ISA. That's neat, but it doesn't "execute python directly" - it runs compiled binaries just like any other CPU. You'd use the same process to compile for x86, for example. It certainly doesn't "take regular python code and run it in silicon" as claimed. A more realistic claim would be "A processor with a custom architecture designed to support python".
  • goranmoomin 1y ago
    Not related to the project in any way, but I would say that if the hardware is running on CPython bytecode, I’d say that’s as far as it can get for executing Python directly – AFAIK running python code with the `python3` executable also compiles Python code into bytecode `*.pyc` files before it runs it. I don’t think anyone claims that CPython is not running Python code directly…
    • hamandcheese 1y ago
      I agree with you, if it ran pyc code directly I would be okay saying it "runs python". However it doesn't seem like it does, the pyc still had to be further processed into machine code. So I also agree with the parent comment that this seems a bit misleading. I could be convinced that that native code is sufficiently close to pyc that I don't feel misled. Would it be possible to write a boot loader which converts pyc to machine code at boot? If not, why not?
    • f1shy 1y ago
      Well it really does not run CPython, but CPython bytecode, compiled down to an assembler. Granted, a very specific, tailored assembler, but still. Anyway, the project is mega-cool, and very useful (in some specific applications). Is just that the title is a little bit confusing.
  • rytill 1y ago
• jonjacky 1y ago
  A much earlier (2012) attempt at a Python bytecode interpreter on an FPGA: https://pycpu.wordpress.com/ https://pycpu.wordpress.com/ "Running a very small subset of python on an FPGA is possible with pyCPU. The Python Hardware Processsor (pyCPU) is a implementation of a Hardware CPU in Myhdl. The CPU can directly execute something very similar to python bytecode (but only a very restricted instruction set). The Programcode for the CPU can therefore be written directly in python (very restricted parts of python) ..."
• hoistbypetard 1y ago
  It seems worth noting that the board you're comparing it to costs <$30 where the dev board you're running on costs $250+. That said... awesome work! I wish I could get to PyCon this year to see your talk. Are you planning to post your core so others can replicate your work?
• esseph 1y ago
  This seems super, super cool!
• chippiewill 1y ago
  Very cool. There's a similar project, Polyphony (https://github.com/polyphony-dev/polyphony https://github.com/polyphony-dev/polyphony) that translates Python directly into Verilog - no processor (A bit like what HLS does for C++). As part of my degree dissertation I tacked on AXI bus support to it to facilitate communication between the CPU and FPGA on a Zynq as a PoC of doing hardware/software co-design with Python. I'd definitely be interested in how this project progresses, particularly if it adds support for integration to the CPU. Some tie-in to the Pynq project could be super fun.
  • brcmthrowaway 1y ago
    You should have used a FOSS fabric bus instead of axi
• tsukikage 1y ago
  > A custom toolchain compiles a .py file into CPython ByteCode, translates it to a custom assembly, and produces a binary that runs on a pipelined processor built from scratch. > Runs a subset of Python What's the advantage of using a new custom toolchain, custom instruction set and custom processor over existing tools that compile a subset of Python for existing CPUs? - e.g. Cython, Nuitka etc?
  • hwpythonner 1y ago
    Compilers and optimizers are great tools for some use cases, but not all. Just to name a few limitations: - Many rely heavily on the CPython runtime, meaning garbage collection, interoperability, and object semantics are still governed by CPython’s model. - They’re rarely designed with embedded or real-time use cases in mind: large binaries, non-deterministic execution (due to the underlying architecture or GC behavior), and limited control over timing. If these solutions were truly turnkey and broadly capable, CPython wouldn't still dominate—and there’d be no reason for MicroPython to exist either.
• psychip 1y ago
  it was cool until i read the line "what is gpio"
• maximemarsal1 1y ago
  [dead]
• ktimespi 1y ago
  Kind of insane that you achieved this. Does your processor support all python bytecode at this point? How do you implement ref counting and garbage collection?
• asford 1y ago
  The benchmark results presented in this page are extremely misleading; you're not comparing to the actual baseline gpio performance available in micropython. Micropython already exposes "viper", which transpiles byte code to machine instructions for highly timing or performance critical code paths. This is reasonably well explained in the micropython docs, which has an example explaining how to ... trigger a gpio and very rapidly. https://docs.micropython.org/en/latest/reference/speed_python.html#the-viper-code-emitter https://docs.micropython.org/en/latest/reference/speed_pytho... Viper runs on device and directly emits native machine code for decorated micropython functions. If you have serious timing requirements for gpio, then this is how you do it. Of course, this is restricted subset of the language compatible with direct native code gen, notably just supporting integer datatypes. However, I would be shocked if this project wasn't also restricted to a subset of the language functionality for your transpilation pipeline. The benchmark should be rewritten to compare against a baseline in micropython using viper. Though this project is pretty neat, the over inflated performance claims would rapidly deflate against a strong baseline.