ubpf VS MAD-NG.docs

eBPF doesn't run in user space in the context of eBPF in the linux kernel. It's verified so that the kernel can be sure it won't loop forever and then gets JIT'ed and run in kernel space.

There are some user space BPF vms like https://github.com/iovisor/ubpf and Solana.

ubpf: https://github.com/iovisor/ubpf

The usual recommendation have been given. Now for more touristic approach what I would like to use if given excuse and time. All those options are mostly written in C:

- QBE [1] - small compiler backend with nice IL

- DynASM [2] - IIUC the laujit's backend, that can and is used by other languages

- uBPF - Userspace eBPF VM. Depending on your DSL the eBPF toolchain could fit your use-case, but this would probably be the biggest excursion.

[1] https://c9x.me/compile/

[2] https://luajit.org/dynasm.html

[3] https://github.com/iovisor/ubpf

There are eBPF-specific userspace implementations you can consider looking into but right now the best support for bpf would be the linux kernel so if the goal is learning you'll most likely want to run linux in a proper virtual machine (e.g. Qemu, VirtualBox, Parallels, etc.)

This may be entirely irrelevant to what you are looking for, but a good widely used finite register-based VM is the eBPF VM in the Linux Kernel. The IOVisor uBPF project (https://github.com/iovisor/ubpf) is a version of the VM in user space.

Did you have a look at LuaJIT? See e.g. http://luajit.org/, http://wiki.luajit.org/Bytecode-2.0, http://wiki.luajit.org/SSA-IR-2.0, and https://github.com/MethodicalAcceleratorDesign/MADdocs/blob/master/luajit/luajit-doc.pdf

It doesn't know that it's an interpreter loop; it just makes a hotpath analysis and then makes decisions on what (variable lenght) traces to optimize and compile. Have a look at https://github.com/MethodicalAcceleratorDesign/MADdocs/blob/master/luajit/luajit-doc.pdf. Actually I'm just a LuaJIT user, not a specialist for tracing JITs. I just wanted to correct the wrong statement that "performance improvements for tracing JITs" "struggle to achieve their goals" with "Interpreters and similar programs that “look like” interpreters". If that was the case, PyPy would not be successful and I wasn't able to achieve the measured speed-up (which btw is higher than the speed-up measured at http://luajit.org/performance_x86.html).