RS will still be responsible for its own compiler. LLVM is not a whole compiler, but a toolkit for optimization and code generation. A compiler uses LLVM to generate code; it is only one piece of the compiler toolchain. The LLVM project RS is working on will replace the existing backend code generator components with a module that calls out to LLVM.

The LLVM code is certainly better tested than anything RS has ever produced, but I do not expect that switching to it will have any noticeable effect on the already-very-rare occurrence of backend bugs. The existing backends are a small fraction of the overall compiler size, and they are some of the most reliable modules in all of REALbasic.

The primary thing you should expect from a switch to LLVM is that performance-sensitive code will likely perform better. The existing backends do very little in the way of optimization, while LLVM offers a wide array of well-tested optimizations. In most situations this won’t matter, but if your app has some tight data-processing loop, you will probably be very happy about what LLVM does to its performance. It is also likely that your executables will be somewhat smaller.

The “Framework” is all of these things – but some can be dead stripped (the stuff built in REALbasic itself) and some can’t (the C++ based stuff)

The move to LLVM is, fortunately for us, something that already knows how to emit machine code for a wide variety of processors. So REAL does not need to spend time creating that. And there are other bits that LLVM includes like optimizations and the infrastructure to add many more.

What REAL has to focus on it the bits that they need to do whether they write the actual compiler or not – converting RB code into some intermediate representation (also known as the “front end”) This front end has to exist for any compiler – it’s just a matter of what the front end turns the RB code into – currently it’s one form and for LLVM it will be in LLVM’s virtual instruction set (see http://llvm.org/docs/LangRef.html)

LLVM then takes that, optimizes it etc and eventually a back end portion emits real machine code from the optimized LLVM code.

Then it all gets linked – I’m not sure if LLVM provides native linkers for all platforms RB targets or not. That may be something REAL needs to create – I’m not that familiar with all the bits that LLVM has.

The RS move to LLVM sounds excellent but also a bit scary during the transition period; as you’ve noted this is no small task.

Obviously smaller builds that also run faster is something we’ve been wanting for years so this great news.

In my opinion having less bugs and more reliability in RB is more important that smaller faster builds.

Hopefully this move to LLVM also means less bugs in RB?

In theory since RS would no longer be writing the complier shouldn’t there be less bugs as the LLVM team is much larger than the RS team and we can bet quality is very important to those LLVM folks (reading the list of LLVM users is noteworthy)?

Additionally shouldn’t the RS team will have more time to fix the bugs in RB unless switching to LLVM is creating more work for the REAL team?

I don’t think I’ve read anything about the LLVM switch reducing the RB bug count which was disappointing.

Bob can you please contribute your thoughts on this?

Thanks.