I'm sure you could, but wouldn't the added overhead defeat the purpose of using either WASM or asm.js? Serious question, because if this could work it's a fun example of "turtles all the way down" in programming.
I can see two ways of interpreting your answer, and neither looks like it gives the desired performance benefits of a plain asm.js fallback:
One: a WASM interpreter in asm.js. Given what this would imply for performance I'm pretty certain that this wasn't what you meant.
Two: a WASM-to-asm.js compiler, possibly in asm.js, that can take downloaded WASM.js files, turn it into asm.js, then load it through the Function constructor.
Assuming you meant the latter: do browsers even support loading asm.js that way? Assuming they do, this would still introduce extra overhead, having to download the compiler, and adding a compilation phase. Of course, since WASM files are binary, the benefit might be lower bandwidth use, so for slower connections it could be a net gain over plain asm.js...
I also vaguely recall that functions creating with the Function constructor don't enjoy all the JIT-compiled optimisations that normal JS functions have, but a quick visit to jsperf[0] seems to disprove this for modern browsers at least. Or perhaps that had more to do with inlining, since they are always created in the global context - an issue that does not apply to asm.js functions anyway.
well it's supposed to be a fallback...you are aware that a fallback is just something better than nothing, right? There are several prototypes already (i.e. https://github.com/lukewagner/polyfill-prototype-1 )
Of course, but I'm basically asking which of the two possible fallbacks would be better:
- test for presence of WASM, if absent fetch the pre-compiled asm.js fallback
- test for presence of WASM, if absent fetch an asm.js WASM compiler to runtime-compile WASM to asm.js.
There's a potential a trade-off in both downloaded size (depending on how big the compiles asm.js file would be compared to WASM + asm.js-based compiler) and loading times.
The prototype you linked looks cool though; too bad development on it seems to have stopped in early 2016. I'll copy their outline of how it works for the lazy:
1. On the main thread, the client kicks off a load
of a URL by calling loadWebAssembly and receives
a Promise<Function>.
2. The polyfill library starts up a worker containing
asm.js code compiled from unpack.cpp concatenated
with the glue code in load-wasm-worker.js.
3. The worker glue code fetches the binary via XHR
then copies the result into the asm.js heap.
4. The asm.js code decodes the binary into asm.js
in the form of UTF8 bytes in a separate region
of the asm.js heap.
5. The worker glue code creates a Blob (a read-only
copy) from a view of just the asm.js UTF8 bytes.
6. The Blob is postMessage()ed back to the main
thread (a non-copying operation) where it is
loaded as a script element with
script.src = URL.getObjectURL(blob).
7. When the asm.js script is executed, it passes the
asm.js module function object to a callback which
resolves the promise in step 1.
I can see two ways of interpreting your answer, and neither looks like it gives the desired performance benefits of a plain asm.js fallback:
One: a WASM interpreter in asm.js. Given what this would imply for performance I'm pretty certain that this wasn't what you meant.
Two: a WASM-to-asm.js compiler, possibly in asm.js, that can take downloaded WASM.js files, turn it into asm.js, then load it through the Function constructor.
Assuming you meant the latter: do browsers even support loading asm.js that way? Assuming they do, this would still introduce extra overhead, having to download the compiler, and adding a compilation phase. Of course, since WASM files are binary, the benefit might be lower bandwidth use, so for slower connections it could be a net gain over plain asm.js...
I also vaguely recall that functions creating with the Function constructor don't enjoy all the JIT-compiled optimisations that normal JS functions have, but a quick visit to jsperf[0] seems to disprove this for modern browsers at least. Or perhaps that had more to do with inlining, since they are always created in the global context - an issue that does not apply to asm.js functions anyway.
[0] https://jsperf.com/function-vs-constructor-vs-eval/7, https://jsperf.com/function-by-constructor