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.
I have started working on AS3C at the end of last year. After a quick prototype the development stagnated and I added just several fixes and tests to the code. Basically I started AS3C as a complete C# newcommer and because of that the code is very ugly.
Due to the fact that I do not have much free time to continue developing AS3C I think it is the right time to release the source-code on the one hand and to let people experiment with it on the other hand.
You can either download the sources and build AS3C manually (you will need zlib.net) or download a binary from trunk/bin/.
When using AS3C you will need the ActionScript from the SVN. Remember that you write real ActionScript code which gets translated by AS3C. There is also one undocumented and very experimental feature existing. If you run as3c.exe -optimize main.swf you could get some speed improvements if you have heavy loops using the Math class. But it could also destroy the SWF so do not forget to make a backup :o)
With the release of the Flex 3 SDK the ActionScript compiler (ASC) became open-source as well. As you know I am working on my own “compiler” to inline bytecode directly with ActionScript. My approach is a post-compile compiler because I wrote it while the ASC was still closed source and ther was no way to do that different.
I still like the approach but it is of course not the best way. The only logical consequence now is to write a patch for the ASC and add some new keywords to it. This would be also easier than what I have to do currently because I am working with bytecode only and the compiler is half a compiler and half a virtual machine. I think it would be great if a community starts to evolve around the SDK and builds a version with more advanced features. Nicolas?
I am so happy — this year I will speak at FITC Toronto! And it is for me the first conference outside of Europe. So what will it be about? It is the first release and session about my currently nameless inline compiler. This tool allows you to write and debug bytecode by writing ActionScript. It includes also a lot of other nifty features like method injection — which is by the way a real killer-feature. If you do not understand it right now don’t worry: you will love it!
The compiler is currently in a working state (although I finally have to support bytecode 0×1b) and I am implementing several optimization techniques. This is not so easy but I hope to find some solutions to enable branch elimination, constant folding and loop unrolling (which is already getting pretty close) to name a few.
I do not want to spoil the fun so any updates are kept private until the FITC for now.
A new year, a new Flashforum Conference. The organizers Sascha and Marc invite you from 2nd to the 5th of June to Cologne. It is my third time at the Flashforum Conference and I think it will be a great event just like the last two years. This time the conference will be also a little bit more workshop-based with two extra days (pre and post conference) full of workshops. I will have one session about Hydra like in Amsterdam and another one about my inline bytecode compiler and optimizer. Be prepared — it will definitly rock.
A little sneak preview for a tool I am currently working on. What you can see is inline assembler instructions in between ActionScript 3 code. You can also place breakpoints and debug your code like you expect it.
The tool has also some other options that can be very helpful. Stay tuned — once it is robust and nice I will let you know for pure low-level fun and optimizations.
__asm(
'.fun:',
Op.findPropertyStrict('public::trace'),
Op.pushString('Hello World!'),
Op.callPropertyVoid('public::trace', 1),
Op.jump('.fun')
);
Would it not be great to write that inline ASM in ActionScript 3 while being able to maintain full debugging capabilities? I think so ;). By the way I hope you noticed that Nicolas just revealed awesome news about future haXe additions.
