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
LLJS).
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
