The use-case would be to test the asmjs-compliant SIMD extensions in Firefox. My understanding is that emscripten generates code that accesses the SIMD object outside the asm.js module.
But, yes, agreed - writing asm.js compliant code is not exactly easy. Perhaps the emterpreter could be used to validate self-written asm.js in EM_ASM? Soeren On Sunday, April 5, 2015 at 2:20:30 PM UTC+10, Alon Zakai wrote: > > We don't have an option for that currently. To have one, we'd need an > option to give useful feedback on validation, since it is really very hard > to write validating asm.js, and I'm not sure how we could do that well. > > It would be much easier if we put it in a separate function, still in the > asm module but not right there in the function you wrote it in. But then it > would still have the overhead of a function call, so not sure how useful it > would be. > > What use case do you have in mind here? > > - Alon > > > On Sat, Apr 4, 2015 at 7:46 PM, Soeren Balko <[email protected] > <javascript:>> wrote: > >> Fantastic - was reluctant to use EM_ASM before because of the eval >> overhead. >> >> Just wondering: is there a way to mark EM_ASM inline Javascript to be >> asm.js compliant, such that it is merged into the asm.js module? Or could >> emcc even validate that automatically? >> >> Soeren >> >> >> On Saturday, April 4, 2015 at 4:55:32 AM UTC+10, Alon Zakai wrote: >>> >>> Progress on >>> >>> https://github.com/kripken/emscripten/issues/2596 >>> >>> has landed on incoming, specifically we now emit EM_ASM contents as >>> normal JS functions inside the .js file that emscripten emits. They are >>> outside of the asm.js module, but they are JS code now, compared to before >>> when they were read as strings from the C heap and evalled. >>> >>> The benefit is that we can avoid evalling in order to use EM_ASM. (That >>> also means you can use the WebIDL binder without using eval, as it uses >>> EM_ASM.) Avoiding eval is both faster and avoids some issues with JS static >>> analyzers that look for eval and flag it as a security concern. >>> >>> This does however change EM_ASM if you are using closure compiler. The >>> difference is that before, closure couldn't see the code, so >>> >>> EM_ASM( do({ prop: value }) ); >>> >>> would be run exactly as it looks. However, now the do({ prop: value }) >>> code is visible to closure, and it might emit >>> >>> do({ a: value }) >>> >>> i.e. it might minify the property name. Normally this is fine and >>> beneficial - letting closure see everything means it can minify across the >>> entire program, which now includes EM_ASM blocks, but you might need to be >>> aware of it in some cases. >>> >>> If you are not using closure compiler, you don't need to worry about >>> this; if you are, you are probably already familiar with this topic, this >>> is just a heads up that EM_ASM blocks are now relevant to it. >>> >>> - Alon >>> >>> -- >> 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 [email protected] <javascript:>. >> 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
