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

From: Thomas Kuther <gimpel@email-addr-hidden>
Date: Mon Jan 22 2007 - 19:31:57 EET

On Mon, 22 Jan 2007 17:00:42 +0100
Leonard Ritter <contact@email-addr-hidden-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

Received on Mon Jan 22 20:15:09 2007

This archive was generated by hypermail 2.1.8 : Mon Jan 22 2007 - 20:15:09 EET