[linux-audio-user] Aldrin 0.9 and llvm (what it is about)

Thomas Kuther gimpel at sonnenkinder.org
Mon Jan 22 12:31:57 EST 2007


On Mon, 22 Jan 2007 17:00:42 +0100
Leonard Ritter <contact at leonard-ritter.com> wrote:

> On Mon, 2007-01-22 at 16:16 +0100, Thomas Kuther wrote:
> > Yes, I (and maybe others) would be interested. I never heard of it
> > before and am just starting to see what it is good for.
> 
> In my 7 years of experience using Buzz, I noticed that often there
> was a big hassle involved with sharing (often quite exotic) dsp
> plugins. Downloading a song for Buzz is usually not enough, you also
> require the machines associated with it, and until you get everything
> running, time passes.
> 
> Lunar was designed to solve that problem by shipping sources and
> precompiled LLVM bytecode per plugin in each song, for all plugins
> required. Another user, regardless of platform and operating system,
> would then be able to open that song without having to acquire any
> additional dependencies. This way, songs saved as ccm modules could be
> shared back and forth without any additional dependencies, allowing
> quick collaboration.
> 
> Even if plugins get updated, old songs would still carry all
> information neccessary to get them working. Legacy code would always
> be connected to the data that needs it.
> 
> LLVM serves as a JIT-compiler, loading and translating the LLVM
> bytecode on runtime. LLVM-GCC is used to translate C++ code to LLVM
> bytecode.
> 
> LLVM is currently being used by Apple to optimize their OpenGL
> pipeline, and considered a possible new default backend for the GNU
> compiler suite.
> 
> > 
> > Currently all i know about it is that it tends to cause massive
> > headaches for packagers and others trying to compile it :)
> 
> LLVM is top notch bleeding edge stuff, and this is the first
> application that requires it. I could, alternatively, resort to
> shipping sources in songs only, and use GCC locally to compile on
> demand. However that approach would bring up issues related to
> sandboxing the code, and only languages supported by GCC could be
> used (where with LLVM, the compiler frontend does not matter).
> 

Thanks very much for the explanation. Also reading llvm.org a bit and
it seems like a good thing to have regarding optimizations.

Regarding my process for llvm-gcc(4) and llvm Gentoo ebuilds.. I'm
getting there slowly :)
Might have been much easier to use the binary builds, but well,
Gentoo.. "use the source if it's available" :)

Regards,
Tom

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.linuxaudio.org/pipermail/linux-audio-user/attachments/20070122/b7628967/attachment.pgp 


More information about the Linux-audio-user mailing list