c4 VS c4

The C4 compiler [https://github.com/rswier/c4] is a self-hosting compiler for a subset of the C programming language that produces executable x86 code. You can understand and audit this code in a couple of hours (its 528 lines).

It could be an interesting exercise to bootstrap up from something like this to a working linux environment based solely on source code compilation : no binary inputs. Of course a full linux environment has way too much source code for one person or team to audit, but at least it rules out RoTT style binary compiler contamination.

I was surprised to see nodes still have two pointers ("references") given that you now know that that the first pointer will always point exactly to the next node. I've see https://github.com/rswier/c4 use that. Granted it doesn't make for the most readable code, but it's even smaller and faster.

VMs with simple instruction sets is a fun topic. Some years ago I got inspired by the amazing rswier/c4 compiler by Robert Swierczek and explored the smallest instruction set I could get away with to create VMs that could run non-trivial workloads.

C4 comes to mind (C in 4 functions), https://github.com/rswier/c4.

have you considered adding a backend for LLVM? perhaps a bit heavyweight, but it could be a good way to get C/C++, fortran, rust, etc. if that's something you'd like!

I use Alpine Linux (no GNU bloat btw), dwm (Sucks less!), and I edit all my C (no bloat language) through busybox ed and compile my programs with (c4)[https://github.com/rswier/c4]

Keep in mind you can create a "usable" C compiler by yourself, and is doable in surprisingly low amount of code. Try https://github.com/rswier/c4/blob/master/c4.c

This part is not terribly difficult, though,—Forth implementations have long explored[1] the road from emiting a list of VM instructions (“token threading”) to emitting a list VM instruction implementation entry points (both “indirect” and “direct threading”, arguably) to emitting a stream of call instructions targeting said entry points (“subroutine threading”) to copying the implementation bodies there (“inline threading”).

With sufficient dedication, you can even obtain the machine code to inline by cutting it out of code compiled from a high-level implementation language, in the name of portability. Gforth does this[2] in the land of Forth, but the more well-known implementation is perhaps the dyngen code generator[3] used in Qemu before the switch to TCG in version 0.10.

Generating machine code isn’t difficult, and neither is modifying a (low-level) bytecode generator to do it[4]. Generaring good machine code is difficult.

[1] http://www.bradrodriguez.com/papers/moving1.htm

[2] https://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Dyn...

[3] https://gitlab.com/qemu-project/qemu/-/blob/v0.9.1/qemu-tech..., rendered as https://web.archive.org/web/20081120011949if_/http://bellard...

[4] https://github.com/EarlGray/c4/blob/master/JIT.md