Adobe Releases C/C++ To Flash Compiler

SnT2k writes "Adobe recently released the beta version of Alchemy which compiles C/C++ code into AS3 bytecode (which runs on AVM2) that can run on the Flash or Flex platform and boasts increased performance for computationally-intensive tasks (but still slower than native C/C++). It was demonstrated last year during the Chicago MAX 2007 to run Quake. A few months later it has been demonstrated to run a Python interpreter and Nintendo Emulator. One interesting tidbit is that the thing is built upon the open source LLVM Compiler Infrastructure."

Comments

Still no contact info, so I'll post here...

[TheRaven64]

On the off-chance that someone from Adobe reads this:

I've been interested in this idea since the presentation at the LLVM dev meeting. I'd be interested in extending clang to use the native ActionScript object model for Objective-C objects, and adding a GNUstep back end to use the native flash drawing primitives so that we can easily port Cocoa apps to run in a browser. Unfortunately, there was no contact information listed anywhere on the presentation or on this site, so I haven't been able to get in touch with anyone at Adobe Labs about this.

Re:Still no contact info, so I'll post here...

[moderatorrater]

And I'd like a pony.

Re:Still no contact info, so I'll post here...

[davester666]

Why does everybody as for a pony, but not a stable to keep it in, or food to keep it alive?

Does Pony meat taste that good?

It has been said

[frictionless man]

It has been said that the reason apple doesn't want flash on their iPhones is that it would create a competing application infrastructure over which they would have no control. I can see this development reinforcing that position.

This seems to further cement flash as a worthy application environment, especially given the perceived problem in flash appeared to be its inefficiency.
Looking forward to better flash games... (Or perhaps not if im not wanting to procrastinate).

Virtualize Everything

[Anonymous Coward]

Wow, I can compile my C/C++ code to run on a slow virtual machine instead of a native cpu architecture.

I haven't had this much fun ever since I discovered the java Virtual Machine written in java.

It brings back the heady days of my 8088.

Re:Virtualize Everything

[MichaelSmith]

JikesRVM has a small "bootstrap" VM that is used to get the main VM going, but after startup everything is run in the main VM (including the main VM itself).

I am getting mental stack overflows just trying to parse that.

More details

[supermansuper]

More details here: http://www.llvm.org/devmtg/2008-08/ (Look for the topic - Flash C Compiler: Compiling C code to the Adobe Flash Virtual Machine)
You post your ideas for Adobe here: http://www.adobe.com/cfusion/webforums/forum/categories.cfm?forumid=72&catid=755&entercat=y These forums are closely watched by the flash player team.

This is not where Adobes priorities should be!

[NouberNou]

I have been working on two large enterprise class applications using their Flex/AIR framework and the performance is absolutely dismal!

The Flash VM is slow beyond belief when getting into large data-structures, event its native array parsing is incredibly slow.

Object instantiation is slower than molasses. We were averaging about 7 seconds to instantiate about 500 fairly complex objects that in most any other language, compiled or interpreted would have easily been created in a thousandth of that time.

The Flash VM's garbage collection is perfectly incapable of doing anything that involves long application run-times and leaks memory all over the place, even inside its native low-level components. It got to the point that even doing any proactive cleanup in our code was totally fruitless and I am sorry to add that a lot of the proactive steps we were taking have been left by the wayside because it is utterly hopeless to release all the memory you have taken back to the system.

Loading an SWF inside another SWF and then disposing of it will not stop the loaded SWF's playback and it does not release it from memory. Instead of Adobe fixing this obvious bug they just added a different method in Flash 10 called "unload and stop" or something like that. This requires anyone who wants to fix this issue to go back and refactor their code!

There are also numerous inconsistencies between applications that run in Flash and those that run in AIR, even though the code base is the same and the idea is that you do not have to change any obvious code to make it work in one platform or another.

Even flashes most basic function, doing vector drawings and animations fails horribly under load. We have had to hack and jury-rig numerous fixes in to compensate for Flash's seemingly random graphical glitches.

If Adobe wants to be taken seriously as a application platform developer, especially one that is used on the desktop they need to get their shit together because right now it feels like a childs toy or half-assed attempt to enter a new market.

Unfortunately the project, the client, and the management have chosen this path for us and we are stuck with it so I really hope that Adobe gets it together because its been a royal pain doing this sort of work on their platform.

Re:This is not where Adobes priorities should be!

[Locke2005]

I have been working on two large enterprise class applications using their Flex/AIR framework...

I think I see your problem right there... there is nothing like using the right tools for the job, and this is nothing like using the right tools for the job. ;-)

Re:This is not where Adobes priorities should be!

[NouberNou]

Dude,

Have you stopped to think that maybe your code has something to do with it?

Yes, many times, and no I do not think my code is ever perfect, or even near perfect, but the proof is in the pudding, you can make very simple test cases and see very obvious drawbacks using just their code/UI components.

One of the problems with working with Flex is that sometimes you have to do things that seem incredibly retarded to get things done. Look at the extensive use of the callLater method in a lot of the Flex SDK code. This method basically says "ok things aren't done, so do it later." Not only does this seem to just patch a problem with not correctly sequencing your methods to fire when they are able to, but it creates huge memory leaks and is horribly hard to debug as you rarely can see past the point of the callLater in the stack.

This reminds me of another problem, in the fact that you can not catch run-time errors at the "root/base" level of the Flash/Flex/AIR application, and even better, if you do not have a debug version of Flash player (and forget it in AIR) then it just completely ignores the error and continues on as if nothing has happened. This then causes Flash to start chucking random errors and glitches that might get caught in your own try-catch blocks much, much later, and you will find that code that works perfectly under every imaginable situation is now glitching with really no known cause. Debugging can be quite the nightmare in Flash.

Re:Increased performance

[drspliff]

The point is that the LLVM project can do far more optimization before being compiled to bytecode than Adobe's ActionScript compiler is doing, and as a result it runs faster.
Yes... Adobe's ActionScript compiler sucks at generating bytecode for their own VM, and even they admit it.

Re:C/C++ Trojan Horse

[noppy]

Compile once, exploit everywhere.