November 2015
Mo Tu We Th Fr Sa Su
<< >>


Virtual Memory API

Posted on Nov 20 2008

Following my previous post about the new Alchemy-related opcodes in Flash Player 10, I was able thanks to people feedback to get the opcodes working in Haxe, and to wrap them with a new Haxe API that is called flash.Memory :

package flash;

class Memory  {

    static function select( mem : flash.utils.ByteArray ) : Void;

    static function getByte( address : Int ) : Int;
    static function getUI16( address : Int ) : Int;
    static function getI32( address : Int ) : Int;
    static function getFloat( address : Int ) : Float;
    static function getDouble( address : Int ) : Float;

    static function setByte( address : Int, value : Int ) : Void;
    static function setI16( address : Int, value : Int ) : Void;
    static function setI32( address : Int, value : Int ) : Void;
    static function setFloat( address : Int, value : Int ) : Void;
    static function setDouble( address : Int, value : Int ) : Void;

    static function signExtend1( value : Int ) : Int;
    static function signExtend8( value : Int ) : Int;
    static function signExtend16( value : Int ) : Int;


The general idea is that you allocate a byte array, of at least 1024 bytes, then you call select() to select it as the current virtual memory.

You can then get/set this memory using the Memory API, the address being a position offset inside your bytearray.

You also have three functions to sign-extend integer values. For instance signExtend8(250) is -6.

I did a quick speed test comparing the different ways of reading / writing memory, and here's the test bellow that will run that for you and give you the results. It creates a structure then read 10000 sequential elements from it, and repeat that 3000 times.

Results show that flash.Memory is 40% faster for reading and 30% faster for writing than using the Flash10 Vector class (for a single byte) - Tested on IE7 / FP10 NOT DEBUG VERSION. I also tested with double values and it performs very well too.


You can start using flash.Memory API right now by updating latest Haxe CVS, or you can wait for Haxe 2.02 to be released in a few days on !

  • Nov 21, 2008 at 01:08

    As usual, Nicolas is the fastest implementer of cool things. Now flash developers can become really jealous for the haX'ers :)

    BTW, Nicolas, it seems flash player detection on this page works a bit wrong. Now I see your test app in FP9 with no message I should upgrade the Flash Player.

  • Nov 21, 2008 at 01:42

    ...which brings me to question, will it work in FP9 if you remove Vector-related stuff?

  • Nov 21, 2008 at 02:10

    Also, it seems to follow that structured data arrays must be split into POD arrays in order to take advantage of this thing. I wonder if some higher level abstraction is possible to work around that?

  • Nov 21, 2008 at 09:58

    Wow! Thats quite impressive! Haxe rocks!

  • Nov 21, 2008 at 10:49


    thank you for your great work. I also had the opportunity to work with Alchemy but I was not that much interested in converting C code to Flash because it is way slower to use the converted code in comparison to hand-optimized code.

    In my opinion the best results of that project are the new opcodes and a new feature for the ASC that Alchemy is using which allows inline asm.

    I am happy that you implemented those new features so quick and it is again a shame for Adobe and their compiler :) How about adding inline asm to the Haxe compiler? I think it would be a good idea -- of course completly platform specific, but for Flash it would already make a lot of sense. Core classes and functions could be optimized specific for each platform and we would get even better results.


  • Nov 21, 2008 at 10:52

    Soon, adobe will send assassins after you ! ;)

  • Nov 21, 2008 at 13:15

    To makc : yes, the blog only checks for FP9 whatever the .swf version. You can try if you wish, but I highly doubt Alchemy opcodes are supported in FP9.

    To Joa : I agree with you with C-to-Flash.

    Inline ASM in Haxe would be indeed a geek feature but so far I was not that much able to get additional performances by writing ASM compared to what the Haxe compiler outputs. But maybe you can prove me wrong ;)

  • hosey
    Nov 21, 2008 at 20:35

    Nicolas, you should add some way of tracking test results. It would be interesting to see how different browsers perform.
    Ubuntu: FP 64 bit alpha
    readArray: 1967
    readByteArray: 363
    readVMem: 182
    readVector: 178

    writeArray: 967
    writeByteArray: 812
    writeVMem: 173
    vriteVector: 235

  • Nov 22, 2008 at 10:34

    Wow, nice opcodes! Just the sort of thing i need for that SCUMM interpreter of mine. :)

    (or i could just compile the c version in alchemy. that is seriously cool)

  • Nov 24, 2008 at 10:14

    Hi Nicolas!
    This is really neat. I actually saw a video where Scott Petersen explains this, but I didn't get it until now. It's the one linked at the bottom of this article that Peter wrote

    Worth checking out!


  • Nov 24, 2008 at 10:15

    Hmm. Link didn't make it through? Trying again:

Name : Email : Website : Message :