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]> 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]. > 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.
