It was already demoed before, but Adobe Alchemy has just been released on Adobe Labs.
Alchemy is a AVM2 backend for LLVM. It means that you can compile C/C++ code to be run on the Flash Player 10.
Let's detail a bit the way this is working :
LLVM is a compiler framework. It has several frontends and several backends. A frontend is typically a C/C++ compiler that will take C/C++ sources files and compile it LLVM intermediate bytecode. A LLVM backend is typically a code generator that will compile the LLVM intermediate bytecode to x86 native code and that will create an executable.
What some guy from Adobe did was to reuse the C/C++ LLVM frontend, then write a small and smart code generator that instead of compiling the LLVM bytecode to x86 or ARM or other native bytecode, compiles it instead for AVM2 bytecode.
AVM2 is the Virtual Machine that is part of the Flash Player. The AVM2 is able to interpret a virtual bytecode which is more highlevel than x86 bytecode (and then can be more easily checked and trusted, which is necessary).
Check this document (PDF) for a list of the documented AVM2 bytecode operations.
As a reminder, the Alchemy pipeline is the following :
.c file -> LLVM intermediate bytecode -> AVM2 bytecode
However, in general, doing so reduces a lot the performances. Especially since the abstraction level of the AVM2 bytecode is a lot higher than the one of the LLVM bytecode, it means that all arbitrary operations such as pointer and memory manipulation which are done in C must be wrapped by using the memory-safe mechanisms which are available in AVM2, such as a
flash.utils.ByteArray to represent the memory data.
Doing that would be very slow, and actually it would be a lot slower than doing it in AS3 or Haxe since you can always better fine-tune your Flash code, while you don't know exactly how things get translated from C/C++ to AVM2...
That's why the following sentence on the Alchemy website raised my attention :
....performance can be considerably faster than ActionScript 3.0...
Knowing that both AS3 and Alchemy output runs on the same AVM2, it would then mean that Alchemy use parts of the AVM2 that are not accessible from AS3...
And indeed, here they are : after a quick check, I could fine 12 undocumented AVM2 opcodes, that seems to be only used by Alchemy : they use codes 0x35 to 0x3E and 0x51 to 0x52. It should be quite quick to find out what they're doing and how they are used by Alchemy, and measure their performance.
This is actually quite good news for Haxe ! Since it already has full Flash10 support, it means that the compiler will be able to use these new opcodes to produce even faster SWF files !
With this and upcoming Pixel Blender assembler support in Haxe , that's a great time for performances addicts !
EDIT : the opcodes are now available in Haxe, see : Virtual Memory API