Scott Petersen presented a project he’s been working on that takes C/C++ code and turns it into ActionScript that is runnable by the Flash Player. A lot of people wanted more info so I sent him some questions. You can take a look at the demo over on Peter Elst’s site.

Ryan Stewart: So who are you? What do you do at Adobe?

Scott Petersen: I’ve been at Adobe almost 10 years. I worked all but the last 5 months or so in the Acrobat Engineering Organization. My current role involves doing research for the Document and Application Technology Group (DATG). I’m doing research into development tools and methodologies for Adobe’s platforms (Flash, Flex, AIR.)

RS: And you blew people away during Sneaks at MAX right? What exactly did you show?

SP: At MAX I showed a demonstration of some experimental tools I’ve been developing that allow cross compiling C and C++ code into ActionScript that can then be used in Flash, Flex, or AIR apps.

RS: Now before we get started this is just a side project, right? Do we have plans to release this?

SP: It’s currently a side project. However, the considerable excitement around the demos will hopefully fuel my own efforts to eventually have a releasable piece of technology. No promises, but I personally would love to see what cool things the community could do with this kind of tooling.

RS: You showed Quake running in the Flash Player right? So how exactly does it work?

SP: I showed Quake running as an AIR application, though the AIR application was only made up of the application descriptor, a single SWF and Quake’s data file. While the SWF would run in shipping Flash Player 9, I cheated a little and optimized access to ByteArray objects in my AIR runtime. This did not entail any new APIs, though. The Quake SWF will happily run in your Flash 9-enabled browser though the performance won’t be quite what you saw at MAX.

The technology itself is essentially a backend for the LLVM compiler infrastructure that emits ActionScript instead of platform assembly code.

RS: Can you explain a little bit what the LLVM compiler is for those that might not know?

SP: The LLVM compiler infrastructure is an amazing set of programs that provides all of the common command line C and C++ development tools like a compiler, assembler, linker, archiver, etc. However, instead of generating and manipulating platform specific assembly code and object code, these tools operate on a platform neutral “assembly language” and byte code.

RS: So you’ve added/tweaked the LLVM compiler so that your C or C++ code compiles down to ActionScript?

SP: Right. I’ve created an LLVM backend that uses the same underlying mechanism as the platform specific assembly language generators for x86, ARM, PowerPC, etc. But instead of generating “real” assembly language, it generates low level ActionScript.

RS: You mentioned in sneaks that you can get some “faux-multithreading” using asynchronous code in ActionScript? Are there other performance or functionality enhancements that you get by converting C/C++ to ActionScript?

SP: One of the big differences between typical ActionScript and typical C and C++ is asynchronous vs. synchronous code. Most ActionScript code is asynchronous meaning that it responds to events. Most C and C++ code is synchronous meaning that there’s a “main” function that runs for the duration of the program. Naive conversion of C or C++ programs to ActionScript would result in a “main” type function that would execute continuously and not give the Flash Player a chance to draw, respond to keyboard or mouse input, etc. To get around that problem, the backend generates an ActionScript class for every C or C++ function. An instantiation of one of these classes more or less corresponds to a C or C++ function invocation. However, unlike the function invocation in C or C++, the corresponding object instance doesn’t do its processing all at once. It has a “work” method that, when called, does a little bit of work and returns. This allows the generated ActionScript to be effectively suspended and resumed to bubble all the way back out to the Flash player so it can draw, etc. If you imagine several instances of these types of objects, one could call the “work” method on each object in turn simulating multiple threads of execution.

RS: So can you take any C/C++ code and compile it to ActionScript right now using your compiler?

SP: Yes, but there are caveats. Any C or C++ code can be converted to ActionScript, but library calls used by any given piece of C or C++ code may or may not be supported by the tools. For many library calls, if a given call isn’t currently supported, it could be by either writing equivalent calls in pure ActionScript or by porting C or C++ implementations of the call. However, some library calls do things the Flash player / AIR runtime can’t do or won’t do (say, for security reasons). In those cases, the Flash player or AIR runtime would need to be extended.

RS: So will you be able to support other languages besides C/C++?

SP: I mentioned at MAX that C and C++ support effectively means some minimal support for any language that has a C or C++ based interpreter. Ruby, Python, PHP, Squeak and others fall into this category. A non-JITting JVM could go this way as well. As a first pass, just port the interpreter/VM. This doesn’t magically expose the Flash Player / AIR runtime’s object model, but it’s a start. A pretty obvious second step is to map that object model into the scripting environment/VM. There is probably a clever way to do this pretty transparently in many cases. Longer term, direct conversion could be developed as well for optimal performance.

LLVM uses the GCC frontend for C and C++ so pretty much any C or C++ GCC can deal with can be dealt with by the tool. One might imagine that other languages supported by GCC such as Java, Objective-C, etc. could make their way into LLVM as well. The way LLVM is architected, it should require very little work (or none at all) to have ActionScript support for those languages after LLVM brings support.

RS: Since people are excited, how can the community help? Are you looking for feedback on anything?

SP: Primarily, I’m interested in what people see using this technology for. That could be C/C++ libraries (Adobe code or open source), desiring to write Flash/AIR apps from scratch with C/C++ or interest in other languages this tech could enable (like Ruby, Java, etc.)

RS: Is there anything else you’re working on?

SP: I spend a fair bit of my time these days trying to decide which of the various uses of this technology to pursue first. Looking beyond enabling various languages on the Flash/AIR platforms, one could imagine something even crazier like conversion of, say, x86 machine code to ActionScript. Perhaps even dynamically. This is by no means right around the corner, but I’d love to some day be able to “free” code trapped in native libraries that have no corresponding source for use with Flash and AIR.

RS: Awesome! Thanks a lot for taking the time to do this Scott. The community was stoked about the demo, so thanks for giving us some insight into how it works.

[tags]Flash Player, C++, C, ActionScript, Scott Petersen[/tags]

Related posts:

1. 3D Tools for WPF and Scott Guthrie on Red vs. Blue
2. Scott Guthrie Trashes AIR and Flex
3. Ahhh, So THAT’S Why Scott Barnes Likes Interactive over Internet
4. Interview with Goowy Chief Architect Jeremy Suriel (Part 2) – Flash and Web 2.0
5. Flash Player 9 Penetration up to 93.3%