The same tool will be able to optimize any SWF file. It does not make a difference if you used the haXe compiler or ASC.

I may be a little confused but is this all haxe based or have you written a sepparate compiler?

This is exactly what TAAS is all about as well. The stack based code gets converted into a TAC representation with stack SSA for branches. I am also working on a SSA for local registers but unfortunately I am currently pretty busy since we are working on the AudioTool 1.0.

Branching into pruned SSA using liveness analysis and dominance frontiers is nearly complete. Getting out of SSA is a different story and not yet implemented as well as converting the TAAS control flow graph back into ca ontrol flow graph of bytecode vertices which might then be converted back into a linear list of operations.

The only cool thing is that the framework is very robust in terms of bytecode. This is absolutely independent of TAAS and works already very well as this example demonstrates.

You can read more about the memory API here:

• http://www.ncannasse.fr/blog/virtual_memory_api
• http://llvm.org/devmtg/2008-08/Petersen_FlashCCompiler.pdf
• http://code.google.com/p/hxformat/source/…/OpReader.hx#201

this is all incredible stuff! About 8 years ago I wrote a JVM bytecode optimiser in perl because I noticed that the java compiler tended to ignore stack based operations. Unfortunately I don’t have the code anymore :-( However I can still remember some of the ideas. I’ll share them with you.

Unfortunatley abc bytecode does not seem to have very good stack manipulation operands (no ROT or OVER as far as I can tell), however it does have DUP and SWAP.

Looking at you inlined byte code I am wondering whether all your fast pushbyte-getint and pushbyte-setint etc could all be done on the stack itself. (as a side note, and I am probably not understanding something because I am new to this, but couldn’t you implement TAAS using the stack? Sorry if that is a stupid question)

Here is an attempt at an example

0×000000 GetLocal0
0×000001 PushScope
0×000002 PushDouble 0.5
0×000004 GetLocal1
0×000005 Multiply
0×000006 ConvertDouble
0×000007 SetLocal2
0x00000a GetLocal1

could be (without address label as I am not sure of opcode sizes)

GetLocal0
PushScope
GetLocal1
Dup
PushDouble 0.5
Multiply
ConvertDouble
Swap

Here you end up with local1 at the top of the stack and local 2 below it. Now I don’t understand how the writefloat(0) and then readint(0) works unfortunately and so I have not attempted to optimize that BUT I am certain that using the stack more will increase you optimisations further.

If you could point me at the docs for the readfloat stuff I will try to write opcodes for the above example that use the stack more.

Do you think this is a fruitful approach?