flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Newman <Capta...@unFocus.com>
Subject Re: [FalconJx] asm.js
Date Thu, 28 Mar 2013 17:29:32 GMT
Editing the compiler is a bit over my head, though I'm happy to through 
out comments on the generated JS code.

Just to brainstorm a bit further, using the asm.js switch idea as 
inspiration, there is a way to finally use Alchemy right from within 
AS3. In thinking about what it would take to add support for this, it 
looks like certain features would need to be avoided to get that kind of 
speed out of it, even if using an AS3->JS compiler (like FalconJx). 
You'd need to strongly type everything (I already do that), and avoid 
some features of AS3 like dynamic types, and probably other features 
too. That's just on the semantics side, even while still using the 
normal GC stack. Adding a meta tag for ASM_JS in the FalconJx tool would 
work there for that half of what asm.js does.

It could also be beneficial for both Flash and asm.js to mark "modules" 
(or perhaps a class in AS3) as "use heap"; (or AS3 meta tag) which would 
instruct the compiler to stuff all the class (or package) variables into 
a bytearray (alchemy) or typed array (asm.js) for faster execution, and 
to avoid GC hiccups. Currently from AS3 there is no way to use alchemy 
byte codes, because AS3 variables are garbage collected - this would 
solve that.

The compiler would need a way to specify manual memory management for 
specific functions, classes and packages, the way Mozilla has done for 
asm.js modules. It would take adding malloc and free for code to use in 
those spaces, and some new compiler checks to make sure nothing in an 
heap class or module is out of bounds for this kind of AOT compilation. 
It seems like this could be taken care of in the compiler, without even 
the need for changes to AVM2, since the tools for this already exist in 
Alchemy (or could be written if Apache has no access to that).

This would basically add a way to manually manage memory from withing 
AS3 through the Alchemy bytecodes in Flash or asm.js in JavaScript (or 

Kevin N.

On 3/27/13 6:26 PM, Erik de Bruin wrote:
> For now, we're using the Google Closure Tools (mainly the GCC with
> JSDoc annotation). This gives use the benefit of having our output
> (structured but human readable JavaScript) recompiled into highly
> optimised and minified 'release' JavaScript.
> Having said that, given the flexible way FalconJx is structured, it
> should be easy to experiment with a different type of JS output. I'm
> willing to help you get started, if you want.
> EdB

View raw message