[haXe] Two patches for dumping AS3 bytecode (was Re: bug? __keys__ ...)

[Nicolas Cannasse]

> I wouldn't consider the memory problem that significant because I assume
> the garbage collector will come along and free anything no longer used. 

Ok, so it's not a memory *leak* but simply the fact that it's using
memory that's a problem for you, right ?

> In my particular case, I need to be more in control of how much memory
> is getting allocated, especially when I am calling these functions many
> times per frame, and thus it would be nice to have some way to loop
> through the keys of a hash or hash-like object without allocating too
> many new objects each time.  It would be nice to understand the
> exceptions I've been getting too.

Well, only a single Array is allocated by __keys__. I could add another
function  iterKeys( callb : String -> Void ); that would call "callb"
for each key, but that would require an additional function call
per-key. What do you think about it ?

> Hopefully these are useful both for optimizing
> critical parts of code, and in general learning how the haXe compiler
> and flash virtual machine work.  Maybe there is already functionality
> somewhere to output this bytecode, but I didn't find it.

Yes, it was not accessible from haXe but from another tool I'm using to
help me developing the Flash9 compiler.

I'm not willing to add the F9 bytecode dump right now because when I
have time to work on the compiler a lot of things might be changed,
based on several bugs that have been reported, and needs for optimization.

The official bytecode dissambler that's available as part of the Flex2
SDK might also be of some help to understand the exact meaning of some
opcodes which were not very clear at the time I worked on F9 support.
I'm still thinking about maybe performing a global opcodes renaming in
Swflib in order to match the names used by Flex disasm.

Anyway, I hope your patches will help your get a better understanding of
the AS3 bytecode.

> Is this list the appropriate place to be sending patches such as these? 

Yes, it is.

> Is there any more information on how these things work, or is this
> really the best way to approach working with the source?

This is a part of the compiler that will have big changes in the near
future, that's why there's not so much documentation right now.

> Part of the reason for including the raw bytecodes in the output is that
> I would like to someday implement some way to inline raw bytecode in the
> .hx source for haXe to compile, for optimization of critical portions of
> code, and for occasions like the __keys__ problem I experienced where
> one would best use flash's own for(... in ...) construct that is not
> accessible from within haXe.  However, I have a lot of learning ahead of
> me.

That's already quite an achievement !

Nicolas