As I posted previously, I was thinking about adding Tiny C Compiler support for Lunar.
That support has been implemented, and I have had one week to test it sufficiently. I removed LUA support, as LUA turned out to be too slow and cumbersome to handle DSP routines. TCC allowed to rewrite all Lunar plugins in C, in a way that feels native to me, but there were some problems turning up:
- Zonaj pointed out that there is no PowerPC support for TCC. At the moment, TCC supports only x86 and ARM backends. Other backends are not planned.
- TCC crashed a lot while parsing erorneous source code. I need to know at least what's wrong with my code.
- Performance of TCC was said to be clearly inferior to GCC.
- There is not much development going on. TCC is freezing.
The most important problem is the lack of PowerPC support, as there are quite a few Aldrin users interested in it. I've been asking on the TCC mailing list for other possibilities to implement a JIT compiler for Lunar, and LLVM was suggested.
Low Level Virtual Machine, generally known as LLVM, is a compiler infrastructure designed for compile-time, link-time, run-time, and "idle-time" optimization of programs written in arbitrary programming languages.
- LLVM has support for multiple frontends, supporting C and C++ among other languages, which means that plugins could be written in different languages than pure C as well.
- LLVM can compile resulting LLVM bytecode for X86, X86-64, PowerPC, PowerPC-64, SPARC, Alpha, and IA-64 platforms.
- Among sourcecode, LLVM bytecode could be stored with the plugin, simplifying access and keeping player dependencies low (only the LLVM backend would be required, no frontend).
- Judging from recent benchmarks, code compiled using LLVM is, compared to the same code compiled with GCC, usually a little bit faster. I was told that DSP oriented code would perform very well.
- Support is good. All the questions I had regarding LLVM have been answered sufficiently on IRC. Four of the LLVM developers, among the project leader, work for Apple, and Apple seems to be using LLVM a lot for various projects. It's not going away.
- Distro support is not so good e.g. Ubuntu Edgy, which I'm using, hosts LLVM 1.7. However, using the special LLVM-GCC binaries provided on their site, building LLVM is a painless process. I expect distro support for LLVM to improve in the future.
- LLVM is not tiny. It is a massive package, however once distros catch up, this shouldn't bother users much.
I am going to replace the TCC code with LLVM code this evening. The results will be released with libzzub 0.2, and utilized in Aldrin 0.9.
Update: Lunar has now entirely been moved to LLVM and loads my default test songs as usual. Some of the trouble I experienced with TCC has now vanished. CPU usage seems to be moderate, but I need better measurements in this regard. All plugins have been converted to C++. Changes are now in the libzzub trunk.
Lunar saves now sources and bytecode with ccm files. Usually, only the bytecode is being loaded, and the source code is stored for reference. If the local build environment is properly set up, source code could be compiled as well.
If you want to have a go at the new backend, you will need to install llvm-1.9.
Thu, 2007-01-18 18:57
Interesting. LLVM reminds me of an old time project (long dead already) called Juice.
Which was positioned as Java killer but of course without as much PR pushing as Java and mostly academic background of its authors, it just died off silently.
Juice is Modula-3 code tho, so less flexible, but idea was the same - compiling source to AST via front-end and then use client-side backend compiler to convert syntax tree into native machine code (JIT).
» reply