link imports requested by wasm module #1571
Conversation
| get_local $value | ||
| call $exampleImport | ||
| ) | ||
| ) |
There was a problem hiding this comment.
this imports example module, linking exampleImport function. It exports a single function exampleExport which when called with an integer will then itself call exampleImport, passing along its return value so we can confirm indeed everything was linked correctly
There was a problem hiding this comment.
For future reader's reference:
This is an "s-expression" textual representation, which was compiled to example.wasm using wabt's wast2wasm, from a build on master at 4492d0cbbb. Both the s-expression and binary are wasm version 0xd. You can probably also use the WebAssembly Explorer (copy/paste into wast section, hit Assemble then Download)
Textual representations of wasm are not yet spec'd so these s-expressions are a convention--what little textual tooling exists so far mostly uses s-expressions. It's extremely likely that a totally different textual format will be standardized. It's mostly used because writing binary by hand is obviously even more impractical.
| .then(function (sourceOrModule) { | ||
| if (typeof sourceOrModule !== 'string') | ||
| return sourceOrModule; |
There was a problem hiding this comment.
This used to return, but my code doesn't because I can't figure out what it would return other than undefined?
| execute: function () { | ||
| _export(new WebAssembly.Instance(m, importObj).exports); | ||
| } | ||
| }; |
There was a problem hiding this comment.
the spec for wasm doesn't currently support linking cyclic dependencies. I'm guessing this whole "setters" thing is to support that for JS modules. Something to keep in mind--it may cause unforeseen problems
There was a problem hiding this comment.
The way this will work out for circular cases is just providing an undefined value for exports not yet defined by execution. Interestingly a WASM module importing a JS module in a cycle, will actually support function export hoisting though. Whether that happens in actual engines will be yet to be seen.
|
Amazing, thank you so much for picking this up sir! Yes there is some intentional duplication between the production and development loaders, although shared code is usually managed through common files in most places, and it probably does make sense to make this a shared function between the two at this point. The processAnonRegister stuff all looks right to me. Will post out a patch here shortly. |
I wasn't familiar with the systemjs codebase, so it's not entirely clear how the internals work. Is the logic intentionally duplicated between
instantiate.jsandsystemjs-production-loader.jsbecause of file size concerns, etc.The whole
processAnonRegister()thing wasn't clear to me as well. Certainly feel free to suggest changes 馃憤