honey-potion VS compilers-targeting-c

Hi all! We are working on an eBPF backend for Elixir. It's called Honey Potion. The project is under development, but it is possible to write some useful programs at this point. For instance, in this video, one of the guys involved explains how to write a program to count system calls.

We have been working on an eBPF backend for the Elixir programming language. The current implementation is on this branch. EBPF is a bit like a virtual machine that runs on the Linux kernel. EBPF programs are typically used to implement network applications. The most interesting aspect of the backend is that Linux uses a verifier to ensure that eBPF programs always terminate and only access memory within allocated bounds.

Hi! We have been translating Elixir to C (which we translate to eBPF) in HoneyPotion. We used mostly Chapter 15 of Appel's Modern Compiler Implementation in Java to implement the code generator (that's "15. Functional Programming Languages"). I think the choice of C has been good thus far. The implementation of Elixir's pattern matching took much work, but if we had chosen a higher level target, we would still have to translate that to eBPF. Here's the entry point for the translator.

We have been working on a tool that translates Elixir to eBPF. We actually translate eBPF to C. Now that we have more stuff working, I really wonder if generating C was a good choice.

That's exactly what Honey Potion does, when we translate Elixir into Linux' eBPF!

https://github.com/dbohdan/compilers-targeting-c

I'm long time fan of programming languages that compiles to C hoping that one day will fall in love with one endlessly! :-)

Somehow related: a list of open source compilers that can generate C code.

If we need a higher-level language in the kernel, it should be a copyfree-licensed language. Lua is already the language of choice for in-kernel scripting. There are many languages that compile to C (Nim, V, Chicken Scheme, etc), which makes them just as fast but a lot less bloated than Rust.

Sadly the best alternative to Apache-licensed LLVM is still LLVM version 8 (the last version under the original license). It should continue to compile well-written C programs (including everything in BSD base), as well as languages that compile to C (Nim, V, Chicken Scheme, etc). But newer C++ features, new hardware support, and ever-improving optimizations would not be available. This would result in a growing number of ports pulling in the latest LLVM/clang as a dependency...

I still use llvm80 (8.0.1_7) (mainly as the Nim / V / Chicken / etc backend), because it's the last Copyfree version, before the switch to Apache license.