We created a new compiler front end that allowed LLVM to understand ActionScript 3 and used its existing ARM back end to output native ARM assembly code. We call this Ahead of Time (AOT) compilation—in contrast to the way Adobe Flash Player and Adobe AIR function on the desktop using Just in Time (JIT) compilation.
"AOT Compilation"?! Amazing!! They should patent this!
The MacRuby guys are doing this as well. (AOT) They are also using LLVM incidentally.
What I'm wondering about is how they do AOT for dynamic code. Do they have every possible path for a data type compiled? This would seem silly..maybe LLVM has some clever ways about this?
No. Your message sends all end up going to the same place where you pass in (a) the target of the send (b) and the message you were sending. This handles dispatch to wherever that's supposed to end up. Objective-C itself handles it this way using objc_msgSend.
In fact... since MacRuby is built entirely on top of Cocoa primitives, it wouldn't surprise me if they've translated all Ruby messages into Objective-C messages and just use objc_msgSend for all of this sort of dispatch.
Never understimate Adobe. Despite their misguided stabs towards DRM (oh god when will they learn) they have some good engineering there.
PDF, Photoshop, Flash, despite all their flaws and sometimes dubious origins, wouldn't have dominated their respective markets for decades if there wasn't also at least a bit of quality engineering in each. ;-)
I don't know why parent is being modded down. Adobe has some fucking mind-blowing engineers, especially on their core teams. Advanced technology labs is putting out parc-quality work in the field of graphics.
That explains how they deal with your code, but what are they doing for the Flash Player bits? All of that wasn't written in ActionScript, right?
For example, if your app needs to play a video, where is the video player coming from? If it's Adobe's own, doesn't that mean Flash-equivalent bits are going to be in every compiled app? In that case, and this would be consistent with what they're saying, the main reason for this AOT compilation instead of JIT is apparently to comply with Apple's legal terms.
They're probably using a similar strategy to Alchemy: map AS3 library calls to a Flash framework implemented in the target language. (In Alchemy's case Scott Petersen implemented a C VM in AS3, linked with the C std lib.) Most likely the entire framework is being bundled with every release, without regard to dependency.
Thanks robc and ed. In that case, I don't think this is as impressive from a technical perspective as some people thought. Again, this AOT compiler is not what made Flash apps technically possible on the iPhone; Adobe could've used this same bundling technique with the JIT compiler. It looks like they've done this just to satisfy Apple's terms.
Ah, so they got Flash on the phone by taking away the bit that makes it suck bells. Good job, Adobe. Amazing what you can do when Apple forces you to not to be craptacular.
It just means that I loathe the Flash runtime on the Mac: it's slow, kills the CPU and as a result sends the fans spinning. This is one reason (beside the business ones) why it was never going to get on the iPhone.
There is no runtime.
+1
http://www.adobe.com/devnet/logged_in/abansod_iphone.html