ubpf VS Befunge

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.

1. C compilers don't do a good job, & thus even CPython, which has historically stuck to rather vanilla C, uses computed goto, as described in https://eli.thegreenplace.net/2012/07/12/computed-goto-for-e...

I resorted to similar techniques in optimizing Befunge: https://github.com/serprex/Befunge (See bejit.c & marsh.c/marsh.h)

2. Rust enums are not variable sized, think of them as tagged C unions, where the Rust compiler can sometimes apply tricks to make Option> the same size as Vec

3. match can specialize for straight forward cases, when in doubt use https://godbolt.org

I've found async to be straight forward anytime I've used it. Promise#then is equivalent to callbacks

async/await often requires very little changes compared to synchronous code, whereas reworking a program into callbacks is much more impactful. & the async/await compilation process tends to produce better performance in addition to this. My first async/await work was a few years ago to increase a data importer's performance by an order of magnitude compared to the blocking code

Here's an example where looping made for a callback that recursively called, using async/await I get to use a plain loop:

before: https://github.com/serprex/Befunge/blob/946ea0024c4d87a1b75d...

after: https://github.com/serprex/Befunge/blob/9677ddddb7a26b7a17dd...

I don't see why people find it so complicated to separate begin-compute & wait-on-compute

I've since rewritten a nodejs game server into rust, https://github.com/serprex/openEtG/tree/master/src/rs/server... handleget/handlews are quite straight forward

You'll also find them used in CPython's ceval.c

I use them in both my C befunge implementations:

https://github.com/serprex/Befunge/blob/c97c8e63a4eb262f3a60...

https://github.com/serprex/Befunge/blob/c97c8e63a4eb262f3a60...