How to compile to binary .wasm file

[Floh]

Hi,

I'm currently playing around with binaryen to compile my demos to WebAssembly, but it looks like this can only generate .wast (text) files, is this correct?

Is there a already way to create binary .wasm file with the help of emscripten?

I would *really* like to test my stuff with the new experimental WebAssembly support in Firefox Nightly and Chrome Canary :)

Cheers,

-Floh.

[Floh]

...and the next question would be:

Once I have a wasm blob, how do I plug it into the browser? 

The Unity demo here is fairly opaque since the interesting stuff seems to happen UnityLoader.js.

Thanks!

-Floh

[Floh]

PS: forgot the demo link :) https://webassembly.github.io/demo/

[Alon Zakai]

It is possible, but not very convenient yet. See

https://github.com/kripken/emscripten/wiki/WebAssembly

Basically, you need to use a plugin script that does the wast=>wasm, because binaryen's binary support is not identical to browsers' (it's a little ahead of the them in following wasm development in some ways, and behind in others).

As for connecting it, it should all just work, depending on what methods for code loading you say during compile time, see

https://github.com/kripken/emscripten/wiki/WebAssembly#binaryen-methods

I'll some more details now to those docs.

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-disc...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Floh]

Ok, seems like I solved the first part, there's a wasm-as tool in binaryen which takes a text .wast file and convertes it to a binary .wasm file.

So, 2 remaining questions:

- how to integrate this .wasm file with the browser module .js file so that it is loaded by the browser? (I compiled with emcc -s BINARYEN=1, and got a .html and .mem file, plus a .asm.js (which I guess is then converted to .wast), a .js file (which I think has the 'runtime environment' and polyfill, a .wast file (which I converted to .wasm), and finally a .wast.mappedGlobals file). 

- what about the mappedGlobals file, is this a temporary file, or will this be loaded at run-time?

Thanks :)

-Floh.

Am Dienstag, 15. März 2016 18:26:37 UTC+1 schrieb Floh:

[Alon Zakai]

Looks like we posted at around the same time :)

That .wasm is not going to run in browsers. But it would run in the binaryen interpreter (veeery slowly). Follow the instructions in the link to generate a binary that browsers can run. Again, this is annoying now since the spec is in flux, but it'll get better over the next few months.

mappedGlobals is necessary. Wasm lacks globlals, but asm.js has them, so asm2wasm needs extra metadata, which it places in that file.

On Tue, Mar 15, 2016 at 11:07 AM, Floh <flo...@gmail.com> wrote:

--

[Floh]

Thanks! I found the place where the HTML is trying to load the .wasm, so that seems to work (for some reason it injected the absolute path to the .wasm file into the .html, so it would try to do "GET /Users/floh/projects/fips-deploy/oryol/wasm-make-release/Clear.wasm".

With that fixed manually, I now get a magic number mismatch from the .wasm loader (currently testing in Chrome), I guess this is what you mean that it won't work:

Clear.js:88157 Uncaught WASM.instantiateModule(): Result = expected magic word 00 61 73 6d, found 00 80 10 80 @+0

But I think I have enough info now to fix the remaining issues :)

Thanks!

-Floh.

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsub...@googlegroups.com.

[Floh]

Ok, I basically got it working, but now I want to remove the big polyfill and only have pure .wasm support, and I can't get the BINARYEN_METHOD flag to work, because python somehow chokes on the '-', and no matter how I want to escape the string, I can't get it to work :/

E.g. this is from the dumped linker command:

-s BINARYEN=1 -s BINARYEN_METHOD='native-wasm' -s 'BINARYEN_SCRIPTS="spidermonkify.py"'

This produces the error:

Traceback (most recent call last):
  File "/Users/floh/projects/fips-sdks/osx/emsdk_portable/emscripten/incoming/em++", line 13, in <module>
    emcc.run()
  File "/Users/floh/projects/fips-sdks/osx/emsdk_portable/emscripten/incoming/emcc.py", line 936, in run
    exec 'shared.Settings.' + key + ' = ' + value in globals(), locals()
  File "<string>", line 1, in <module>
NameError: name 'native' is not defined

Without the BINARYEN_METHOD it works, but produces a 3 MByte big .js file.

This is on OSX, both in bash and in fish shell. Python version is 2.7.11

Halp :)

(I'll try for now to hack the default in wasm.js-post.js to native-wasm, but any idea how to solve that slightly embarrassing problem is welcome :)

Worst case may be: remove the '-' from the binaryen-methods, or replace with underscore?

Cheers,
-Floh.

[Alon Zakai]

How did you try? On linux this works for me

-s "BINARYEN_METHOD='native-wasm'"

(one type of quotes for the entire thing, one type of quotes for the native-wasm string).

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-disc...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-disc...@googlegroups.com.

[Floh]

Ok, with some really dirty hacks I got what I wanted (just the pure wasm stuff, no polyfill):

- don't compile with BINARYEN_METHOD, since for some reason my setup gets confused about the '-' in the method names
- in binaryen/src/js/wasm.js-post.js, change the default method to just 'native-wasm'
- in emcc.py:1832, remove the 'not shared.Settings.BINARYEN_METHOD' from the if to prevent inclusion of wasm.js polyfill if no BINARYEN_METHOD is set
- finally, in the generated .html, I have to manually remove the absolute filesystem path from the .wasm URL (no idea what's going on there, this doesn't happen for the normal asm.js case)

And with this, I get a nice demo running, yippie :) (see attachment)

Next I'll try to somehow clean this up and create a pure WebAssembly-version of the Oryol samples page (like this: http://floooh.github.io/oryol/)

-Floh.

[Alon Zakai]

Nice!

Can you please file an issue for the absolute path thing? I'm not sure I understood yet what the symptoms are.

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-disc...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-disc...@googlegroups.com.

[Floh]

Erm, guess that was the one version I didn't try. That works! Thanks :)

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsub...@googlegroups.com.

[Floh]

Here it is: https://github.com/kripken/emscripten/issues/4170

-Floh.

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsub...@googlegroups.com.

[Floh]

For reference: here are the requires steps to compile the Oryol samples for WebAssembly, please ignore all the 'little hacks' I wrote about in this thread :)

http://floooh.github.io/2016/03/17/oryol-webassembly.html

Cheers,

-Floh.

Am Dienstag, 15. März 2016 18:26:37 UTC+1 schrieb Floh:

[Gareth Morgan]

Is this still the best path to follow to run a .WAST file in Chrome Canary?

[Floh]

I'm not sure if a .wast file (ASCII) can run directly, I only tried .wams (binary), but I think the general workflow still applies.

However I'm currently getting validation errors both in Firefox and Chrome with the latest Binaryen and Spidermonkey tools.

For instance in Chrome:

InfiniteSpheres.js:137 Uncaught WasmModule::Instantiate(): Compiling WASM function #19:<?> failed:Result = ExprI32ReinterpretF32[0] expected type f32, found ExprGetLocal of type f64 @+62

And in Firefox:

TypeError: wasm validation error at offset 213331: type mismatch: expression has type f64 but expected f32

Cheers,

-Floh.

[Alon Zakai]

For firefox, if you use the same build to both create the wasm file and run it (i.e. the same for spidermonkey shell that binaryen calls to, and the browser you then run it in), then it should work - if not, that's a bug. But if it's different builds, then this is expected, the binary format will be constantly changing until it is stable.

For chrome, it's a little trickier since the tool to emit wasms is in a side repo, I'm not sure how to verify that they are in sync.

For both, there will be "checkpoints" in time where all tools and all browsers (latest versions of all) should work. The intention is that at each such point, you'll be able to emit a binary by emcc+binaryen and run it in browsers, without needing extra tools. Next checkpoint is 0xb, probably a few weeks away.

--

You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-disc...@googlegroups.com.

[Ben Smith]

If you're getting the same errors from Chrome and Firefox, then I'd guess there's an issue with the producer (asm2wasm, I'd guess). Have you taken a look at the generated .wast file?

On Monday, April 11, 2016 at 11:40:09 AM UTC-7, Alon Zakai wrote:

For firefox, if you use the same build to both create the wasm file and run it (i.e. the same for spidermonkey shell that binaryen calls to, and the browser you then run it in), then it should work - if not, that's a bug. But if it's different builds, then this is expected, the binary format will be constantly changing until it is stable.

For chrome, it's a little trickier since the tool to emit wasms is in a side repo, I'm not sure how to verify that they are in sync.

sexpr-wasm-prototype regularly updates to the lastest v8 build and runs the full spec test suite. The binary format has been stable since the demo, so there shouldn't be any skew here.

There is also a binary decoder included in that repo (wasm-wast or wasm-interp will work), so you can test to see if the type checker fails there too. 

 

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsub...@googlegroups.com.

[Floh]

Yeah, I'm currently not testing with my own compiled Firefox, just the current Nightly, I guess there's a delay when the latest Binaryen changes hit Nightly (or Chrome Canary).

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsub...@googlegroups.com.