From Adobe Labs
What is Alchemy?
Code name “Alchemy” is an experimental research project and tool chain from Adobe that allows users to compile C and C++ code that is targeted to run on the open source ActionScript virtual machine (AVM2). The C/C++ code is compiled to ActionScript 3.0 as a SWF or SWC that runs on Adobe Flash Player 10 or Adobe AIR 1.5. Alchemy is intended to be used with existing C/C++ libraries that have few OS dependencies. The generated content is within the security constraints of the AVM2, and cannot bypass Flash Player security protections.
What can you do with Alchemy?
With Alchemy, developers can reuse existing C and C++ client or server-side code in applications that run on Adobe Flash Player 10 or Adobe AIR 1.5. With Alchemy, it is easy to bridge between C/C++ and ActionScript 3.0 to expand the capabilities of applications on the Flash Platform, while ensuring that the generated SWCs and SWFs cannot bypass existing Flash Player security protections.
What are Adobe’s plans to productize Alchemy?
Alchemy was originally released as a research project and prelease software available to assess the level of community interest in reusing existing C and C++ libraries in Web applications that run on Flash Player and AIR. There have been no additional updates to Alchemy since its release. While this technology preview was not intended for production applications, there have been persistent requests from developers asking for official support in the Flash runtimes.
We’ve been listening and have decided to invest in creating an improved version of Alchemy, which we plan to release as part of a paid production offering for commercial development. Non-commercial use will be free of charge.
What will the next iteration of Alchemy do?
The production release will offer significantly better performance and productivity over the Labs prototype. By re-architecting major portions of the technology, we aim to enable code execution approaching native performance, scalable support for large code bases, full debugging support, up to 75% reduction in code size, and seamless integration with ActionScript – all while reaching browsers on 98% of connected computers.
When will this new release be available?
This new offering will be available with an update to the Flash runtimes in the near future and will replace the current Alchemy prototype. In the meantime, we are temporarily including the prototype in the initial releases of Flash Player 11 and AIR 3. As always, we continue to advise developers not to use the Alchemy prototype for production content.
Will my existing content continue to work?
Although we will be ending the Alchemy experiment, existing content created using Alchemy for Flash Player 10.x and AIR 2.x will continue to work in future versions of Flash Player and AIR. The new, fully re-designed Alchemy commercial offering will be needed to deliver Alchemy-enabled content that requires Flash Player 11 / AIR 3 and beyond, and we plan to make it free for non-commercial use.
How do I find out about future updates to Alchemy?
We encourage developers to ask questions, discuss, and share feedback with other prerelease users and the Alchemy development team in the online forums. Visit the Alchemy forum.
Why did Adobe pursue this research project?
Alchemy was designed to bring the power of C and C++ libraries to Web applications. The goal of this research project was to enable Web developers to re-use the massive amount of existing C and C++ code and expand the capabilities of applications deployed on Flash Player or AIR. Developers could re-use existing code that has already been tested and do so in a way that was safe to run in the browser in the Flash Player sandbox.
What type of projects benefited from Alchemy?
Alchemy was intended to be used with C/C++ libraries that have few operating system dependencies. It is ideally suited for computation-intensive use cases, such as audio/video transcoding, data manipulation, XML parsing, cryptographic functions, image encoding, PDF rendering or physics simulation. Alchemy was not intended for general development of SWF applications using C/C++ or for porting software that has platform specific features that were not supported in Flash Player.
How is Alchemy related to “FlaCC”?
Alchemy is the code name for the project formerly known as “FlaCC”, which was demonstrated at the Adobe MAX developer conference in Chicago in 2007.
Does Alchemy allow a developer to add new functionality to the Flash Player?
Yes and no. No, because Alchemy compiles to ActionScript which is run within the Flash Player. This means that all security restrictions and sandbox rules apply to that code. So, you could not for example, compile a C project that accesses a USB device directly, and expect it to work within the Flash Player. Yes, because the optimized ActionScript byte code generated by Alchemy can execute significantly faster for certain computationally intensive use cases. This means that projects that were too CPU intensive for the Flash Player before, may now be feasible.
Is code ported using Alchemy less secure than ActionScript?
No. The Alchemy-generated SWCs and SWFs cannot bypass Flash Player security protections and are subject to the same security restrictions and sandbox rules that apply to ActionScript code.
Is Alchemy-compiled code faster than ActionScript 3.0?
For computation-intensive use cases, such as audio encoding/decoding, data manipulation or cryptographic functions, performance of code ported using the Alchemy tool chain can be ten times faster or more than native ActionScript 3.0 and anywhere from 2-10 times slower than native C/C++ code. Specific results will vary depending on the project and will not always be faster than pure ActionScript code.
Why can't the ActionScript compiler generate byte code that executes as quickly as Alchemy?
Compiling with LLVM tools (included as part of Alchemy) allows compile and link time optimizations to be applied that the ActionScript compiler does not use as yet. In addition, for operations involving ByteArrays there are opcodes that are optimized for performance, which the ActionScript compiler does not generate today.
The Alchemy team is working closely with the Flash Player and compiler teams, and Adobe expects that many if not all of the performance improvements from Alchemy will find their way into the shipping compilers and players.
Do I need to know C or C++ in order to use Alchemy compiled classes in my ActionScript project?
You do not need any prior knowledge of C or C++ in order to use SWCs created by Alchemy from C / C++ code. If you want to compile existing C / C++ code into a SWC, then you need at least a basic understanding of C and/or C++.
Can Alchemy compile languages other than C and C++ into ActionScript?
Currently, the only supported languages are C and C++.
How can developers share their ported libraries?
We encourage developers to share the C and C++ libraries that they have ported using Alchemy by posting links to their libraries.
Should I use Alchemy-generated code in my application in production?
Alchemy is prerelease technology that is not supported by Adobe and may contain bugs. Alchemy should not be used to generate code for use in production.
What does Alchemy include?
The Alchemy tool chain includes a set of tools for building, testing and debugging C/C++ projects, example projects and documentation. It is based largely on the LLVM compiler project.
What is LLVM?
LLVM is a set of tools for creating and manipulating "low level virtual machine" bytecode. LLVM includes gcc/g++ based front-ends for converting arbitrary C and C++ code to LLVM bytecode.
What tools can I use to compile C or C++ code with Alchemy?
The tool-chain shipped with Alchemy includes a modified GCC compiler - llvm-gcc. This must be used to compile your C files for use with Alchemy. However, you can drive that compilation from Xcode, Visual Studio, Flex Builder, and other IDEs via makefiles, ant scripts, etc.
How does Alchemy work?
Alchemy works by converting LLVM bytecode to ActionScript 3.0 (AS3) source through an Adobe-authored LLVM back-end. This AS3 source is then compiled using a special version of the ActionScript Compiler to ActionScript bytecode (ABC). This ABC output is then bundled into either a SWF or a SWC depending on your compile options. The resulting SWFs can be executed using Flash Player or bundled into an AIR app. The resulting SWCs can be built into a larger Flash, Flex or AIR application just like any other SWC.
Does C / C++ code have access to Flash Player APIs?
Yes. C/C++ code can access Flash Player APIs through the "AS3.h" API. You can also instantiate new ActionScript class instances through the “AS3.h” API.
Why are Web applications that incorporate Alchemy-compiled code generally larger in size?
There are several factors involved. The C standard library and other required support code adds a fixed overhead of about 140KB. In addition, the code that is generated by Alchemy is not as small as it could be; in particular, C “static” data are not represented very efficiently at present.
Does ActionScript provide APIs or syntax that allow the opcodes in Flash Player 10 to be used from ActionScript programs?
The standard ActionScript compiler, ASC, does not make use of the opcodes that were introduced for Alchemy, nor are these opcodes exposed as classes or methods in the ActionScript libraries. As a result, ActionScript programmers using the standard ASC cannot make use of the new opcodes. However, ActionScript programs can make use of libraries created with Alchemy, and thereby access these opcodes indirectly.
Alchemy uses a modified ASC that has an “in-line assembler” syntax that allows the new opcodes to be used from ActionScript programs, however.
Why are the opcodes introduced in Flash Player 10 not available to standard ActionScript?
The opcodes provide access to a new memory that is completely segregated from the memory used for ActionScript objects. In general, ActionScript values cannot be stored in this new memory, and values that are stored in the new memory do not behave like ActionScript values.
The in-line assembler facilities provided by the modified ASC in Alchemy are considered experimental at this time, and as they are used by machine-generated programs only they do not need to be convenient nor to fit seamlessly into ActionScript.
Are the new opcodes faster than new Vector data type in Flash Player 10?
The new opcodes help implement the C memory model, an untyped linear array of bytes. Programs using this model are frequently faster than programs using the memory model of ActionScript, a collection of interlinked, typed objects. Additionally, Vector operations have not been optimized as heavily in Flash Player 10 as have the new opcodes. Therefore an Alchemy program working on an array of C data may run faster than the corresponding ActionScipt program working on a Vector of ActionScript values.
On the other hand, the C program has very limited error checking, and C programs frequently have errors where they address memory outside the intended array. Accesses to ActionScript Vectors are, however, fully error checked. The error checking tends to make it less time consuming to develop ActionScript code than C code.
Where can I find documentation on the opcodes?
No documentation on the opcodes has been published at this time.
Can I write pure ABC programs to produce highly optimized bytecode?
Adobe does not provide any tools that allow you to write ABC programs by hand. However, the ABC specification is public and it is possible for interested programmers to write tools that aid in ABC programming. In some cases hand-written ABC programs might be faster than the corresponding ActionScript program, because the ABC program might be able to make more efficient use of AVM2 facilities.
What are the compiler optimizations in LLVM that do not yet exist in ASC?
ASC performs few optimizations at this time, whereas LLVM performs many of the standard optimizations one would expect a C compiler to perform—including inlining, loop unrolling, strength reduction, and loop invariant code motion. Alchemy uses LLVM to optimize the code it generates, resulting in bytecode that is often better than that produced by ASC. AVM2 performs some standard optimizations as it translates bytecode to machine code (whether the bytecode was generated by ASC or Alchemy/LLVM) but as a general rule the better bytecode generated by Alchemy allows AVM2 to produce faster machine code.
Is Adobe committed to ActionScript and ActionScript performance?
Adobe remains fully committed to improving ActionScript by adding features to the language and by improving its performance. We are continually working on improving the quality of ASC, both its correctness and the quality of its generated code, as well as the performance of the virtual machine.
How can the community assist in improving ActionScript performance?
Knowledgable community members can help improve ActionScript performance by participating in the open-source development of both AVM2 and ASC, which is included in the open-source Flex SDK.
What are “inline opcodes” and how can I use them?
Inline opcodes are individual instructions for AVM2 that are placed inside ActionScript source text, so as to access directly facilities of AVM2 not available in ActionScript, or to make more efficient use of AVM2 facilities. Standard ASC does not allow the programmer to use inline opcodes at this time, though the modified ASC in Alchemy does.
How can developers compile their code to AVM2 in the best possible way?
Certain low-level, performance-critical libraries that operate only on primitive data can be written in C and compiled with Alchemy. Other code should be written in ActionScript and make use of the low-level libraries.
As a general rule, ActionScript programs run faster when they use Vector data instead of Array data, and when they declare the types of parameters and variables that hold primitive data (int, uint, and Number).