This one supports some LLVM IR instructions: https://github.com/caozhanhao/llvm-brainfuck
There's a list of others here, with asm2bf seeming the most complete: https://esolangs.org/wiki/Brainfuck_code_generation
Interesting to see how the author decomposed the problem:
- C raytracer https://github.com/mTvare6/rayfuck/blob/master/ray.c
~~ LLM refactor of the C code ~~>
- SSA-style C raytracer code https://github.com/mTvare6/rayfuck/blob/master/ray_ssa.c
~~ c2dsl.py helper script (compiler) ~~>
- DSL raytracer https://github.com/mTvare6/rayfuck/blob/master/ray.dsl
~~ dsl2bf.py helper script (another compiler) ~~>
BF raytracer https://github.com/mTvare6/rayfuck/blob/master/ray.bf (~22 mb of unreadable nonsense)
The dsl2bf compiler has a bunch of examples of implementing slightly higher level abstractions atop BF primitives. E.g. "go" to move the pointer to a different offset, destructive & non-destructive copies, all the way up to things like division -- BF only natively offers unary addition/subtraction.
If we have a read of the code of the final compiler, dsl2bf.py, the abstractions used in that code are relatively simple: global variables, local variables, lists, dicts, for loops, function definitions & function calls. It is feasible to implement a simple compiler like dsl2bf in BF itself, with sufficient head scratching. Again, quite unpleasant to try it directly in BF, but a next step could be to implement the dsl2bf compiler in the DSL itself - extending it if necessary, then compiling it with itself to produce a dsl2bf compiler implemented in BF.
I hadn't considered self-hosting the compiler, but having put it into works, I probably will.
This was the render the speed up version gave: https://paste.c-net.org/SpikingCarbs
[dead]
One way to start could be to ignore performance of the data structure.
The first main job dicts are being used for is the `mem` dict mapping a key (variable name) to some value record.
A data structure that supports Store(K, V) & V = Get(K) could be something like an stack allocated array of (Key, Value) pairs, that you search through using linear search to implement Store & Get. It wouldn't be very fast, but you probably don't have too many items in a typical DSL program. You'd need to implement some kind of stack or so on - or perhaps you could get away with reserving some fixed capacity.
The first value of each instruction would then always be one of a fixed set of opcodes, variables their IDs, and numbers left as-is (and we've invented machine code :)). Then (K, V) is always fixed-size and laid out predictably in memory, so the linear-search approach sounds reasonable.
> rg var ray.dsl | wc -l
142
> rg func ray.dsl | wc -l
6
+28 for opcodes, bringing it to 176. So it works for this interesting program, the raytracer, but the compiler likely requires way more. Maybe not the 4 cells I've been using, but 2^16 = 65k would be enough buckets but unique names.
> Pretty impressive, but depending on the complexity of the program not as impressive as writing whatever it is in assembly directly
I'd make the case assembly is easier here, given the DSL isn't much different in terms of it's experessiveness, and jumping around is easier in assembly too. Registers change the whole thing.