hwpythonner

7 ms·

1. 1.▲
   by 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 C
2. 2.▲
   by hwpythonner 1y ago

   PyXL is a bit more direct :)
3. 3.▲
   by hwpythonner 1y ago

   PyXL deliberately avoids tying itself to Python’s high-level syntax or rapid surface changes. The system compiles Python source to CPython ByteCode, and then from ByteCode to a hardware-friendly instruction set. Since it builds on ByteCode—
4. 4.▲
   by hwpythonner 1y ago

   Fair point if you're looking at it through a strict compiler-theory lens, but just to clarify—when I say "runs Python directly," I mean there is no virtual machine or interpreter loop involved. The processor executes logic de
5. 5.▲
   by 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 execu
6. 6.▲
   by 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 toggli
7. 7.▲
   by 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).
8. 8.▲
   by hwpythonner 1y ago

   Thank you!
9. 9.▲
   by 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
10. 10.▲
    by hwpythonner 1y ago

    Good question — I’m not 100% sure. I'm not an expert on Ruby or JS internals, and I haven’t studied their execution models deeply. But in theory, if the language is stack-based (or can be mapped cleanly onto a stack machine), and if th
11. 11.▲
    by 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,
12. 12.▲
    by 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.
13. 13.▲
    by 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 design
14. 14.▲
    by 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
15. 15.▲
    by hwpythonner 1y ago

    The source isn’t public at this stage. I'm still deciding the best path forward after PyCon.
16. 16.▲
    by 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 t
17. 17.▲
    by 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-fr
18. 18.▲
    by 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
19. 19.▲
    by 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
20. 20.▲
    by 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 — av
21. 21.▲
    by 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
22. 22.▲
    by 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/se
23. 23.▲
    by 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 i
24. 24.▲
    by 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 acces
25. 25.▲
    by 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 instructio
26. 26.▲
    by 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
27. 27.▲
    by 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 performanc
28. 28.▲
    by 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
29. 29.▲
    by hwpythonner 1y ago

    You make a great point — type information is definitely a huge part of the challenge. I'd add that even beyond types, late binding is fundamental to Python’s dynamism: Variables, functions, and classes are often only bound at runtime,
30. 30.▲
    by 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