[gst-devel] Orc-0.4.1 - The Oil Runtime Compiler

[David Schleef]

On Sat, Jul 04, 2009 at 10:13:14AM +0200, Sebastian Dröge wrote:
> When do you plan to push this changes to the main GIT repository?

Probably won't be pushed any time soon.  I'm not planning to write
or maintain #ifdef HAVE_ORC's everywhere, so it's probably not
appropriate for master until Orc gets more user testing, cross-platform
testing, and perhaps a few more features.

There are several hurdles that need to be addressed:

 - Whether Orc will be a required dependency *for users*.  Orc
   will probably grow features soon that makes this irrelevant.

 - Whether Orc will be a required dependency *for developers*.

 - Whether to make the .orc source the canonical description of
   the functions implemented.  Pro: orcc automatically generates
   test code.  Cons: yet more crap for developers to learn, plus
   the generated C code is not easy to understand.

 - Orc is still developing rapidly enough that it will either
   need an ABI bump soon or start accumulating crufty API.

The summit would be a convenient time to discuss such things.  I
don't really need to be involved.  I'm committed to making Orc a
useful tool for GStreamer, 

I'm tentatively planning an ABI bump once Orc handles roughly all
the liboil functions that Schroedinger and GStreamer use, which
should be some time in September.  Hopefully there will have been
enough user testing by then that it can be an ABI that is stable
for several years.

> And what will happen if orc is used on an architecture (mips, alpha, x86
> without MMX and stuff)? Will orc simply fail then or is there a slow
> fallback implementation?

It uses the C backup function that orcc generates.

> - The multichannel conversion routines need some kind of matrix
> operations. Is this what you mean with 2-D array mode?

Partly.

> Will it also be possible at some point to write things like
> for (i = 0; i < N; i+=2)
>   d[i] = s[i] + s[i+1]
> with orc?

You can do that right now using something like:

  select0lw t1, s1
  select1lw t2, s1
  addw t1, t1, t2
  select0lw t3, d1
  select1lw t4, d1
  addw t3, t3, t1
  mergewl d1, t3, t4

It's a little clumsy, but any strided operation is clumsy with
vector operations.  (Also note that you can't currently read a
source twice, you have to copy it to a temp variable first, but
that is a bug.)

Concerning the orc Makefile target in you other email, I'm planning
to make orcc also generate independent C code, so if HAVE_ORC is not
defined in config.h (for example), the generated code won't need Orc
headers to compile, nor will you need orcc installed to generate
those files.  These are tradeoffs that aren't unique to Orc.



dave...