Jukka just pushed a windows-specific fix for infinite-looping, so this might work for you now.
On Wed, Mar 23, 2016 at 2:43 PM, Charles Vaughn <[email protected]> wrote: > So I've gotten a chance to try this, but on test code it seems to enter an > infinite loop. I left it running overnight. Is there some steps I can take > to debug what's being run and why? > > On Tuesday, March 8, 2016 at 9:06:48 PM UTC-8, Alon Zakai wrote: >> >> 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. > -- 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.
