Orc-0.4.15

[David Schleef]

Only about 3 months late...

Orc-0.4.15
==========

This should have been release much earlier.

 - Protect global resources with mutexes.  Duh.  This solves a bunch
   of bug reports.
 - Restore c64x-c backend.  Untested.
 - Convert MMX and SSE backends to a new instruction scheduler.
 - Add alignment and size hints to parser.


ORC - The Oil Runtime Compiler
==============================

(and OIL stands for Optimized Inner Loops)

Orc is a library and set of tools for compiling and executing
very simple programs that operate on arrays of data.  The "language"
is a generic assembly language that represents many of the features
available in SIMD architectures, including saturated addition and
subtraction, and many arithmetic operations.

At this point, developers interested in using Orc should look at the
examples and try out a few Orc programs in an experimental branch
of their own projects.  And provide feedback on how it works.  There
will likely be some major changes in ease of use from a developer's
perspective over the next few releases.

The 0.4 series of Orc releases will be API and ABI compatible, and
will be incompatible with the 0.5 series when it comes out.  The first
release of the 0.5 series is anticipated to coincide with the release
of GStreamer 1.0.


Features:

 - Users can create, compile, and run simple programs that use the
   vector extensions of the CPU, all directly from an application.

 - Users can compile Orc programs to assembly source code to be
   compiled and used without linking against the Orc library.

 - The generic assembly language can be extended by an application
   by adding new opcodes.

 - An application can add rules for converting existing or new opcodes
   to binary code for a specific target.

 - Current targets: SSE, MMX, ARM, Altivec, NEON, and TI C64x+.
   (The c64x target only produces source code.)

 - Programs can optionally be emulated, which is useful for testing, or
   if no rules are available to convert Orc opcodes to executable code.


More information:

  Web: http://code.entropywave.com/projects/orc/
  Download: http://code.entropywave.com/download/orc/


Questions and Answers:

 - Q: Why not let gcc vectorize my code?

   A: Two reasons: first, since Orc's assembly language is much more
   restrictive than C, Orc can generate better code than gcc, and
   second, Orc can generate code for functions you define at runtime.
   Many algorithms require gluing together several stages of operations,
   and if each stage has several options, the total amount of code to
   cover all combinations could be inconveniently large.

 - Q: Why not use compiler intrinsics for SIMD code?

   A: Compiler intrinsics only work for one target, and need to be
   hand written.  Plus, some compilers are very picky about source
   code that uses intrinsics, and will silently produce slow code.
   And, of course, you can't compile intrinsics at runtime.

 - Q: How big is the Orc library?

   A: For embedded users, the --enable-backend configure option can
   be used to disable irrelvant targets.  Compiled with only one target
   (SSE), the library size is about 150 kB uncompressed, or 48 kB
   compressed.  The goal was to keep the uncompressed size under
   about 100 kB (but that failed!).  A typical build with all targets
   and the full ABI is around 350 kB.


Caveats (Known Bugs):

 - ?


Future directions:

 - Addition of more complex loop control and array structures.

 - Addition of an option to compile the Orc library with only the
   runtime features for a single target, e.g., for embedded systems.
 
 - Addition of rewrite rules, which convert an instruction that cannot
   be converted to binary code into a series of instructions that can.
   This is necessary since assembly instructions on most targets do
   not cover all the features of the Orc assembly language.