90% of the job takes 10% of the time, the remaining 10% of the job takes 90% of the time.

No offense, but REAL Software’s track record hasn’t been particularly stellar when it comes to estimating how long projects are going to take.

Then it comes time to move to Cocoa. Trying to use the old event model requires jamming a square peg into a round hole. Since Windows and Linux have event models that are modern like Cocoa, we ripped out all the plumbing left over from the Classic Mac OS days and modernized the event model. This refactoring was expensive but worth it in the long run.

As for LLVM, we already have it working for RBScript which was the biggest part of the job. The move to LLVM is nothing like the move to Cocoa and you won’t be required to deal with both of those at the same time because we will still be supporting Carbon for a while and as of today, I don’t see any reason why you would be forced to use Cocoa with LLVM.

Lastly, I don’t know where Bob got his information about how long it might take to get LLVM working with our debugger, but our engineers that are working on this have told me that getting the debugger working is not going to be a big job at all. It’s not going to be trivial, but it’s not going to be months of work either.

So don’t worry about it. These are all steps in the right direction. Yes, sometimes they take longer than any of us would like but they are still progress.

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.