lauf VS skybison

I have a VM lying around: https://github.com/foonathan/lauf

Yeah, that's what I'm doing in lauf. When returning, the stack segments stay allocated and can be reused when it reaches the end again.

I'm working on lauf, which is a low-level bytecode Interpreter: https://github.com/foonathan/lauf

I've been working on a generic bytecode interpreter the last couple of months. It reached a point where I needed to test it in a real compiler, so I've started writing a C interpreter.

I'm currently writing a C interpreter using my lauf bytecode interpreter. It's developed live on Youtube where I'm streaming every Tuesday and Thursday at 17:00 CEST/CET: https://www.youtube.com/c/foonathan

The parent comment is referring to the primary Python interpreter and runtime, CPython, not to libraries. There are of course other Python implementations, but [the only C++ one](https://github.com/tekknolagi/skybison appears to be unsupported.

Kind of! In my fork I run microbenchmarks on each PR. So you can see on, for example, https://github.com/tekknolagi/skybison/pull/456, that the change had a 3.6% improvement on the compilation benchmark. If you expand further, you can see a comparison with CPython 3.8. Unfortunately Skybison is still on 3.8.

This is also the pointer tagging scheme from the Ghuloum paper. I did not design it. Another tagging scheme I did not design is the Skybison scheme, which uses 0bXXX...XX0 to tag integers and 0bXXX...001 to tag heap pointers. This makes heap reads very easy (bias by -1 in addressing mode).

Skybison is a Python interpreter and I'm curious what the results look like. We also have some benchmarks in benchmarks/benchmarks.

If you take a look at the Skybison Python runtime, I would be happy to chat and help you poke around integrating it: https://github.com/tekknolagi/skybison

I am, in fits and starts, writing a bytecode optimizer for Skybison that takes advantage of type information.