Nitpicking, but just as anything digital the SWF opcodes essentially are 1s and 0s, too. :)
Anyway, the new VM supports JIT compilation to native machine code. I must admit I don't know if /all/ code gets JIT compiled or only hotspots, and I don't know if it will be recompiled for each use to "hardcode" variables, but that would also have implications. Mark On Wed, Jul 30, 2008 at 8:21 PM, Kerry Thompson <[EMAIL PROTECTED]> wrote: > Juan Pablo Califano wrote: > >> If you mean decompiling the push method itself, you can't because it's not >> actioscript but a native code, implemented directly in the player. > > Nice work, Juan Pablo. > > The code you have been posting prompts me to comment on the underlying > mechanism of Flash. I know, from experience, that a lot of Flash coders (and > Director, and Java) don't understand about bytecode vs. native code. > > If you're writing in a true compiled language like C++, your code will > compile to machine language specific to your CPU. Machine code is 1's and > 0's, the on/off switches that are the basis of any binary computer. > > Flash is cross-platform, though. It has to work on Intel processors, > PowerPC, and others. It has to work on different OS's like Windows, Mac, and > Unix. The machine code is different for every processor, and the > implementation is specific to an OS. So, the Flash compiler can't compile to > machine code. > > Instead, Macromedia, and now Adobe, have written a player for each of the > supported platforms. The player is in machine code (ones and zeros), but our > ActionScript code is not. ActionScript compiles to an intermediate bytecode, > or token. The player reads these tokens, and executes the appropriate > machine code. > > That's what makes Flash slower than C++, and also more secure--it's much > more difficult to write malicious code if you don't have direct access to > the machine, but have to go through an interpreter. > > This idea has been around for 25 years or so. The first implementation I > used was UCSC Pascal, which, like Flash, compiled down to an intermediate > token which was, in turn interpreted and executed by the player (we called > it a "virtual machine" back then). It has only been in the last 10 years or > so that machines have gotten fast enough to run this sort of code > satisfactorily. > > If you understand this, you can find the bottlenecks in your code more > easily, and optimize it. Loops are often the main culprit, as they have to > interpret the bytecode each time through the loop. Also, if you're working > with something with a fixed length like an array or XML nodes (really the > same thing), it's faster if you store the length of the array in a register > variable. An illustration: > > var arrLen:int; > arrLen = myArray.length(); > for (var i:int; i < arrLen; i++) > > works faster than > for (var i:int; i < myArray.length(); i++) > > Cordially, > > Kerry Thompson > > _______________________________________________ > Flashcoders mailing list > Flashcoders@chattyfig.figleaf.com > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders > _______________________________________________ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
