What is FlaCC all about?
If you paid close attention during some of the Adobe sessions at Flash on the Beach you’ll have heard about a project called FlaCC, basically a way to compile C and C++ libraries to ActionScript bytecode.
I haven’t seen a whole lot of people talking about it as of yet even though - if this works out - it is in my opinion one of the most exciting developments in the last few years!
From what I can tell this project goes back to what we saw presented by Scott Petersen during the sneak peek sessions at MAX Chicago 2007, the most impressive of his demo’s was without a doubt running a cross-compiled version of Quake in the Flash Player (or an AIR app as it turns out).
Here’s the video I recorded back then:
There was a huge amount of interest in this project and shortly after Ryan Stewart had the opportunity to interview Scott Petersen to find out more:
http://blog.digitalbackcountry.com/?p=1095
The first mention of FlaCC during Flash on the Beach was at the Adobe Town Hall meeting, where Paul Betlem answered a question about possible support for a Dynamic Language Runtime.
I don’t have a direct quote but in effect he said that FlaCC was in development, it allows for C/C++ code to be compiled to ActionScript bytecode, and will be made available to developers in the not too distant future.
On Wednesday during the “The Yin and Yang of Flash” session we were given a little more background information.
One of the major use cases for FlaCC seems to be to allow a form of native extensibility for the Adobe Integrated Runtime. Since it would compile C/C++ down to ActionScript bytecode this would ensure cross-platform compatibility, which is a key concern for AIR.
Paul Betlem mentioned that the C code compiled down to ActionScript bytecode runs up to 10 times faster than ActionScript 3.0 (and about twice as slow as native C code) making it a good candidate for complex math and other operations.
Since FlaCC was brought up as a reply to a question on Dynamic Language Runtime support, this could conceivably mean work is being done on having an interpreter for a language like Python ported to the Flash Player. This is in line with what Scott Petersen presented at MAX 2007 and I believe that same point came up in the Adobe Town Hall meeting as well.
In any case, exciting times ahead and can’t wait to see this in action!
This work, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 2.0 Belgium License.
it’s very interesting. When they showed it LAST YEAR at max I was psyched though I’m still not 100% sure how it’ll finally get released. As a plug in to AIR… or for the web player? The premise is awesome but how it’s deployed is unclear to me.
Don’t miss the MAX 2008 keynotes. FLACC will be there.
Ted
I would love also to see Merapi “integrated” into AIR or the Flash Player : I mean a way to launch silently a java app and then use the Flex-Merapi bridge.
More info about FlaCC is on Scott Petersen’s presentation:
http://llvm.org/devmtg/2008-08/Petersen_FlashCCompiler.pdf
wow, excellent find Zohar — thanks for the link!
cool post
don’t forget about the video you posted on twitter:
http://llvm.org/devmtg/2008-08/Petersen_FlashCCompiler_Hi.m4v
I have got to get my hands on that! I love C++ programming! I want to write C++ AIR apps.
If one can compile C to AS bytecode and run 10x faster than equivalent AS code compiled to AS bytecode, doesn’t it mean that Adobe could also work on improving the AS->AS bytecode compiler to generate faster running bytecode? Honestly I would prefer they spend resources on this instead of allowing me to get C code running in Flash VM!
He mentioned using server-side PHP and other technologies in the SWF, wouldn’t most of the robustness of the server native functionality be disabled by the flash player’s security sandbox, and wouldn’t the same go for C/C++ code? I agree that C/C++ compiled to run directly in the AVM is a pretty awesome idea, especially with regards to the thread emulation, but I’m still left wondering about flash security (and the flash player’s memory management).
If, however, using this method to compile bypasses the standard security measures that usually constrain AS code (compiled in Flash or Flex), why can’t we just go backwards; create an XSL that converts AS3 to C++ and compile that directly to a SWF. That way we could leverage the power of threads and other things usually outside the flash sandbox.