Introducing YALT: Because some people don’t like LLVM.

We all wait for our program to compile (or someone else’s) and we keep thinking “This is it. It’s going to fail”. And sometimes it does. But sometimes (thankfully), it doesn’t. Then we discover a bug (Or two. Or three) and we all know how it goes from there.

However, this “stress” is only amplified when you are using a compiler you wrote. Then, you also have to worry about if the compiler itself is going to crash, output the write file (whether that be assembly, an executable, an object file, etc….), and if your test program works.

Most of the time, this stress happens during the final stages of getting a minimal working compiler. Code generation. Oh, the nightmare that is code generation. Thankfully, we now have libraries like LLVM and B3 (B3 is still pretty new, though).

So whats the problem, you may be asking, if we already have libraries for dealing with this stuff? Well, for one, the documentation for these systems is terrible (just look up on Quora reasons for not using LLVM). And also, these libraries are highly optimized for a certain type of language (namely C/C++ like, procedural with a small bit of Object Orientation), so if you want to build a duck-typed dynamic programming language, your out of luck.

Why create something new?

Why can’t we just all suck it up with LLVM? Well, LLVM has some more legal issues. The great majority of active development of LLVM, is financed by Apple, Google, and Qualcomm. LLVM is quietly becoming a strategy for companies to assert their own proprietary intellectual property, as industry
standard.

Consider, for example, Go (one of my favorite languages). Go is an entirely Google-owned language, and LLVM supports it as a first-class front end. However, use of LLVM’s Go implementation, implies acceptance of Google’s terms to use Go.

I imagine that a brilliant but evil lawyer could use those terms, to find a way to make trouble, for almost any user of Go.

Also, other LLVM like libraries have very little documentation, or are very new (like B3).

So why create a new one if there are already in development ones? Why over saturate the market? That brings me to my next reason for developing
YALT (which by the way, stands for Yet Another LLVM-Like Thing): educational purposes.

It seems like someone like me would learn allot from developing something like this. Don’t get me wrong, I know how some stuff works (I’m in the process of creating a breadboard computer, and have made several
emulators/VMs). But I don’t know a lot about Optimization techniques or
back-end compiler code generation (BCCG).

That being said, I don’t care if this project is widely used. I would be
cool if it was, and had a small team of contributors behind it, but
that’s not my goal here.

How will YALT (Yet Another LLVM-Like Thing) be different?

Do you like my acronym? Anyway, YALT’s goal is to not be a copy of LLVM.
It’s goal is to be a lightweight, versatile, compiler back-end library,
and to address some concerns about LLVM. I will list three here.

First, LLVM errors on it’s own. You don’t get a chance to see what the errors
are, and act accordingly. LLVM just bails out the entire program.

Second, is the optimizations. LLVM automatically optimizes your code like
there's no tomorrow (or so I’m told). It’s pretty hard to turn this off,
and the optimizations are mainly for C/C++ like languages (Rust,
however, does it’s own optimizations and then passes the optimized code
to LLVM).

Third is how hard it is to interact with the API, unless you want to spend
time fiddling around with compilers and headers and libraries, etc….
which is not something you want to do. Wouldn’t you rather an easier
way?

Can I learn all of this stuff too?

Of course! Just stay tuned to the YALT Github Repository, and look at what each commit has to over.