For an interpreter, there's the emterpreter in emscripten. Not sure it's the simplest possible, though, it's more designed for speed.
On Tue, Mar 8, 2016 at 6:21 PM, Aidan Hobson Sayers <[email protected]> wrote: > This sounds neat! I've been pondering on an 'early-executor' and this is a > really nice demonstration of both viability and utility. > > The things I've been thinking about is attempting to start running `main` > as far as possible, so non-deterministic functions would end up bubbling up > to the beginning. Are there any simple asm.js interpreters (i.e. reduced js > interpreter) you're aware of? I suppose would need to be the first step - > unlike the 'global ctors' work which looks like it effectively does 'dirty > checking', I'd imagine this pass doing data dependency analysis to skip > over e.g. `printf` calls since they might not have much impact on the > actual flow of code (depending on the memory accesses etc inside these > calls). > > On 8 March 2016 at 23:25, Alon Zakai <[email protected]> wrote: > >> The incoming branch (now 1.36.1) now has a new optimization when building >> to JS with -Oz. It will eliminate C++ global constructor functions >> aggressively, removing them from the codebase, removing the need to call >> them during startup, and removing code that would otherwise be used only by >> them. >> >> This makes -Oz when compiling to JS slower to compile than before, almost >> 2x slower. To avoid that, you can disable this optimization (-s >> EVAL_CTORS=0), or just use -Os. In general, -Oz is kind of the "try at all >> costs to reduce code size", so it felt natural to include this optimization >> there. >> >> The benefit can be noticeable. For example, this removes the 2 global >> ctors that doing any C++ iostream usage would normally bring in, that >> create the standard streams. This reduces code size by a few percent, as >> well as JS compilation time, and startup is faster also because we can jump >> right to executing main(). In general, of course, we can't remove all >> ctors, as it might do something with side effects like printf or malloc, >> which we can't optimize away. With EMCC_DEBUG=1 in the env, you'll see >> logging that shows an error in such a case (which you can use to optimize >> your codebase, if you want). >> >> This optimization was inspired by Cheerp's PreExecutor ( >> http://blog.leaningtech.com/2016/02/cheerp-preexecuter-compile-time.html >> ). That made me wonder, doesn't LLVM already do this? Turns out, yes, it >> does, but at the IR level, and as a result is not as successful as it could >> be, due to the complexity of LLVM IR. But at the asm.js level things are >> very simple - in fact, this optimization just literally runs the code in a >> JS sandbox, and sees if it ran without using anything nondeterministic. >> That's after all the LLVM complexity was lowered out, and is basically >> guaranteed to work when it should work. More details at >> >> https://github.com/kripken/emscripten/blob/incoming/src/settings.js#L699 >> >> - 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. >> > > > > -- > Aidan > > Currently co-authoring a book on Docker > <http://manning.com/miell/?a_aid=aidanhs&a_bid=e0d48f62> - get 39% off > with the code 39miell > > -- > 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.
