If you have been following me on Twitter you might have figured out that I am working on a new project. During the last couple of months I have learned a lot in terms of code analysis and optimizations. And I am not talking about ActionScript optimizations — this is as interesting as a piece of cake. I mean stuff like sparse conditional constant propagation or loop-invariant code motion. This is where it gets interesting.
In order to perform such optimizations considering ActionScript there are two options:
- Extend the existing ActionScript Compiler
- Write a compiler that does not take ActionScript as the input but ActionScript Bytecode like AS3C
Extending the ASC for this task is not worh considering in my opinion and since AS3C is really buggy I decided to start from scratch. The result is high-level framework to deal with SWF, SWC and ABC files including abstract structures for control flow analysis or bytecode permutations. The idea was to make manipulations as easy as possible by hiding the complex nature of ABC files which contain ActionScript bytecode and the description of classes, their visibility etc.
Since this basic framework is now complete I started with the next step: transforming the bytecode into a stack-less representation. The reason is quite simple. The bytecode and AVM+ are using a stack-based form for various good reasons. But optimizing stack-based code is hard because the stack plays such an important role since nearly all instructions depend on the stack’s state, thus on the preceding operations.
The idea is to transform the stack-based bytecode into a stack-less three-address-code. This is why I started working on TAAS, Three-Address-ActionScript. TAAS is a stackless representation of ActionScript bytecode and typed as long as the type can be determined at compile-time. This means also that method calls are solved and that it is possible to have an optimization step to inline those for instance.
Unfortunately it is absolutely not trivial to convert bytecode to three-address-code since the control flow of a method has to be considered as well for instance. This and many other things caused me a lot of headaches during the last week. Most problems are solved but I have not implemented all instructions of the AVM+ yet. Although I can already transform the 3D lorenz attractor to TAAS for instance and all types are solved correct.
Now what is the next step? Of course converting TAAS to a static-single-assignment form which is perfect for optimizations.
Having a powerful framework opens up a lot of possibilities. There are frameworks available for Java which convert Java bytecode to SSA as well which could be converted to TAAS and finally to ActionScript bytecode. One could also start implementing great features like Code Contracts.
I will talk about my work and results also at FOTB this year.
Sounds really cool, but over my head technically. I do like the fact that you dont hate java. :)
Hi Joa,
Great work! This kind of code analysis opens up great possibilities for bytecode optimization. Hopefully one day the dumb AS compiler will be able to perform these kind of optimizations on its generated AVM bytecode. The possibility of cross-compiling JVM bytecode is intriguing, too.
This is cool stuff. Maybe the HaXe folks would be interested in this too?
Very interesting.
But I have a question. What you use as a platform for this tool? AIR? Java? .Net? C++?
I am thinking on making a SWF compiler/decompiler and ABC optimizer written on AS3 (hopefully without need of AIR). Possibilities for usage of it would be endless.
I think my brain just exploded. Awesome work dude, can’t wait to see what can be done with this kind of optimization.
very looking forward to your FOTB talk… sounds like amazing results.
Kevin: It does not matter who compiled the original input SWF. It would work for haXe, ASC or future compilers. Although, you have to specify/load all external libraries you used to link against (e.g. playerglobal.swc) for the typing system. This is only in terms of haXe a little bit strange, where you do not have a playerglobal.swc — so you would need the Flex SDK or at least the Flash Player builtin libraries in addition. You could also check out Tamarin and use the builtin.abc, toplevel.abc and playerglobal.abc.
wonderwhy-er: I have choosen Java for this task. Having an ActionScript 3 library for this could be fun, but compiling an executable or interacting with Ant/Maven is an awkward task considering the fact that you have to run the AVM+ to allow direct file I/O without the use of AIR.
Doing this with Java was painful enough since you do not have unsigned data types etc. but this logic is just placed in Input- and OutputStream implementations.
Very exciting stuff in terms of improving tools for Flash developers.. just thinking, you could probably make an abc Forth compiler as a side project. Wouldn’t take too much of your spare time :)