qbe-rs VS Befunge

You can try buildling you own backend like llvm. A good example or starting point is probably QBE since it is extremely small but very functional.

How big is the whole backend? I've heard that it is small but I wanted to compare it to QBE which is around 8 KLoC and it is quite interesting too.

I think QBE might be what you're looking for?

https://c9x.me/compile/

As far as I know, there is QBE, which is actually kinda underrated, and Cranelift, mainly designed for JIT compilation

Before that, I had spent a bit of time working with QBE, which is much simpler and really easy to write a frontend for. I switched to libgccjit though, because I got frustrated with a few of the things lacking from QBE (like the ability to easily keep track of where different variables live on the stack). I think for many hobby language projects, QBE would be a good option (my project was off the ground very fast using QBE, and I got pretty far before I ran into limitations I couldn't easily work around).

If one of your parameters is size/complexity of the backend and you prefer something smaller, have a look at qbe and cwerg

The alternatives are generally hidden inside of another compiler. The big exception seems to be qbe (https://c9x.me/compile/) however since the author appears to have written this code without peer review, it's not easy to read it's source code.

So my question is this: if a backend like QBE (~12k Loc) was added to Zig and Zig only had to compile Zig code (no C, etc) for that QBE backend -- about how many LoC would that Zig need to be?

GCC is written in C++ these days, so something like QBE(https://c9x.me/compile/) would be needed.

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...