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….), if your test program works. and 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 and (B3 is still pretty new, though) LLVM B3 . 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 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. Quora Why create something new? Why can’t we just all suck it up with LLVM? Well, LLVM has some more 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. legal 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 to use Go. acceptance of Google’s terms 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 , and look at what each commit has to over. YALT Github Repository
