asm.js from TypeScript?

Topics: General
Mar 27, 2013 at 11:32 PM
I'm curious about the feasibility of compiling into Mozilla's asm.js modules from the type notations provided in TypeScript. Care would still be needed to make sure things worked in the asm.js restrictions (like making sure not to use dynamic variables, etc.), but certain things seem very doable, like changing a function signature with type information and setting up the function body to be statically AOTed according to the asm.js specifications.

One thing I'm not clear about though is whether an implementer of asm.js must implement heap management, or if it's ok to just use normal JS variables (it seems like it is, but it's a bit over my head).

Just curious about the feasibility of this. :-)

Kevin N.
Mar 27, 2013 at 11:51 PM
From my perspective, I believe it is doable but you lose certain features of asm.js. The main thing I believe you lose is the ability to have ints and the signedness of numbers. TypeScript doesn't differentiate between double and int (just has number). So you'd likely still be forced to do the same |0 suffix or + prefix like native asm.js. At least that's my limited understanding of how it'd work. How to best port constructs such as modules and classes to the asm.js subset woudl require more thought.
Coordinator
Mar 28, 2013 at 12:05 AM
Something along these lines certainly could be possible longer term for TypeScript. It's a direction we thought about in early TypeScript planning, and we want to keep the door open. LLJS takes an approach along these lines, and some similar techniques could be applied very naturally within the context of TypeScript. Would be interested in hearing any more thoughts on what would be most interesting in this direction.
Mar 28, 2013 at 1:37 AM
I could imagine TypeScript adding annotations to the generated JavaScript for execution engines to use for optimization. I was kind of hoping, given that TS started in the IE team, this was one of the original intents. Do we need a language subset for this though?

One thing that I always wondered why TypeScript doesn't cover is different numeric types. Adding double, float and integer types has value even outside of these optimizations. number could still be supported in parallel to the more restrictive types.
Mar 28, 2013 at 3:49 PM
I guess TypeScript would need to add a few additional math types (and maybe some other stuff - I'm not clear from the docs on how to pass functions around, etc.). Once those are in, TypeScript could compile int into x|0, and double into +x, etc. The nice thing as they point out in the Mozilla doc is that these are backward compatible, so x|0 converts to integer even in older engines (even if the runtime locks aren't the same). This means it definitely has more use than just for asm.js.

Certain other features would have to go unused, such as dynamic variables in an asm.js module. So there would need to be some way to mark an entire module as asm.js (to follow the asm.js convention just use "use asm"), then some additional compiler checks could be added to make sure a particular module is compliant with asm.js.

The last thing, I'd bet a lot of the benefit of using asm.js and LLJS is the heap emulation, and the control over GC that gives you. I'm not sure how that could be worked into a language like TypeScript in a useful and unobtrusive way (addition of malloc?). If something like this were implemented, it could be a separate feature. Something like "use heap" or another kind of switch, where LLJS style heap emulation would be compiled out, instead of just using standard JS variables. (I wasn't clear if this part was actually necessary to get working in asm.js - I think it isn't).

It seems this could be very useful for creating modules where performance is vital (such as physics, or some graphics work). This would be especially true if MS, Google and Apple pick up the asm.js AOT functionality. ;-)
Apr 29, 2013 at 11:34 PM
Typescript can even help make asm.js happen. No doubt asm.js will mature along with the larger ECMAScript standard. TypeScript can make it palatable now; just as it helps smooth over the differences in the module patterns (Universal Module Definition support would be nice on that score, by the way). Two trends:
  • Low level libraries (zip libs, underscore etc., libs, and node-related libs) will all need to be rewritten in asm.js
  • The entire ecosystem needs rebuilt on the class library model rather than the bag-o-function model
Typescript can be a key catalyst to make this all happen because it can hide the disjoints and make the whole seem like a cohesive language/environment.

I say, Full speed ahead! Of course maturity will mean change. Typescript can provide abstractions that support for this change without the pain. Typescript, right now is a shell. Incorporating the static features of asm.js (optionally-of course) can make the JavaScript code, the content in the shell, a palatable general purpose language. The "missing features" as mentioned above will mature into the language over time. There's no reason we can't have static code right now.
Sep 11, 2013 at 2:35 PM
I would love to see TS compiling to asm.js, but I can wait a while - let's not burden the team with one more compile target at this time, and let's get TypeScript itself where it is going.

It seems like a very natural fit though, TS and asm.js, and I really hope the team will consider this and evaluate feasibility of doing this in the future...
Nov 19, 2013 at 7:32 AM
I think it's odd that this is a feature that has to be requested: asm.js is just a formalization of emscripten output so IE, Chrome, and Firefox have already been optimizing for this type of code. It's an incremental improvement over standard design patterns, the additional math libraries, etc, are not a big deal. Unlike the speedups Dart achieves with Chrome, an asm.js compile target (or, rather, an llvm target) would allow MS to push these optimizations to all of the browsers. I mean, who wouldn't switch over to the TypeScript compiled version of your favorite library if it was faster and provided a drop-in replacement?
Jan 2 at 8:09 PM
I certainly would support the idea of adding an asm.js backend to TS. asm.js does not support object properties or the new-operator, so you would need to add your own memory management. Emscripten cross-compiles malloc() for this purpose. We have cross-compiled Java to asm.js with some impressive results. The type information that TS adds is an ideal foundation to emit asm.js. Since it has been several months since the original post, could one of the MS guys comment on any updates?
Mar 31 at 2:28 AM
As TypeScript 1.0 beta is now out, is this being considered as a potential future development?