A better as3 compiler? The logical consequences that never happened

More than an year ago, Joa Ebert posted a brief summary of the “logical consequences” of Adobe’s opening of the Flex SDK sources: now that the sources for the actionscript compiler were open, the community was free to branch out a more advanced one. Function inlining, mixing as3 and opcodes, optimised integer math (I do NOT want to work with Numbers), compile-time evaluated constant expressions; the list of possible enhancements is long. Why bother? Because the as3 compiler makes little use of the avm2′s true performance potential (things got worse with fp10 and the unavailable to as3 Alchemy bytecodes), performs no compile-time optimisation of your code and outputs redundant bytecode overall, especially in the case of integer arithmetics.

An year passed, and noone really raised the question again. Well, maybe kind of. Alchemy did create quite a buzz, due to the obvious absurdity of c++ being quicker than as3 when compiled down to abc, and some of the mighty few did start thinking about how (and why) on earth would such a thing be possible. Some explainations came along, and the dark magic of the LLVM kind of concealed the fact that the one and only as3 compiler is crap. Note that the Alchemy compiler overcomes the shortcomings of the as3 compiler by outputing assembler when necessary.

Well, if the dreamed of as3 compiler is a far-fetched thing to strive for, Joa Ebert’s as3c gave the community a glimpse into the potential for extention of the existing asc. As far as I know, as3c is still the only way to inline assembler in the body of a program that will boil down to abc. Joa’s efforts have been pretty much discontinued however and some opcodes are left unimplemented. Also, the as3c workflow is kind of heavy – one could hardly wire as3c into FlashDevelop for instance.

On the other hand, there is a way to produce highly optimised abc, if one is ready to give up the language. Nicolas Cannasse‘s haXe has pretty much all the language features an as3 coder craves for, such as enums, type generics and, recently, an api to the new avm2 Alchemy-related opcodes. What trully rocks the boat is that the haXe compiler has ability to boost code performance in the avm2 to a much greater extent than what compiled as3 gets: indeed, the haXe compiler boasts with features such as function and constant inlining, optimised integer math, and also a strong expression optimiser that does some last minute code refactoring for performance. Finally, the haXe format library even enables you to write in assembler, which you can assemble to bytecode, load an run on the go.

But seriously, if one guy can design an entirely new language, able to compile down to highly optimised avm2 bytecode, with all the language features missing in as3, why can’t an entire community (and an interested corporation, for that matter) produce a better compiler for the already exisiting as3? Obviously, it is noone’s responsibility to take on this task (community-wise; Adobe should take the matter seriously); but in my humble opinion it’s everyone’s responsibility to be talking about it.

I believe that we should put forth a community project which would at least define some of the parameters of the as3 compiler of tomorrow.

P.S. A question about haXe and format.abc: Nicolas, is there no way to make bytecode insertion happen at compile time in haXe (as opposed to during runtime with the format library?) Generating and loading swf-s is extremely sweet, but ties one down to writing entire classes in opcodes; mixing haXe and opcodes, with an asm{} keyword for instance, would be much more flexible, and absolutely amazing.

Bookmark and Share

3 Responses to “A better as3 compiler? The logical consequences that never happened”

  • You could write a program in haXe/Neko using the hxformat library that would :
    a) read a SWF
    b) do some replacements, for instance replace calls to Asm.myOpcode() by the actual corresponding opcode
    b) write back the SWF on hard drive
    This is a bit what Joa was planning to do with AS3C, although much more easy to implement thanks to haXe enums support.

  • Forgot to say : the main issue is that ABC bytecode uses a lot of indexes into global tables, so this is one reason why it’s not easy to write inline assembly directly, since you need to update the global tables as well.

  • Nicolas, thanks for the quick reply! I’m afraid I’m not the guy for the job though. Among the many reasons, I don’t even know where to start from.

    Still, features such as this will only strengthen the haXe adoption trend; we all know that the Flex SDK will very likely never provide anything similar.

Leave a Reply