Branch updates and Emterpreter landing

[Alon Zakai]

incoming has not been merged to master for a while now, due to overall people being busy, and some breakage related to the experimental SIMD stuff. Hopefully we'll get to that next week.

One thing that might delay it, but shouldn't, is that the emterpreter branch was just merged to incoming. This adds a new feature, so it shouldn't disrupt existing things, however to implement it I had to add a bunch of things and do some refactoring in various places. Locally the test suite passes but we'll see on the bots.

The new feature on the emterpreter (=emscripten interpreter) branch that just reached incoming is the ability to compile a project into a binary bytecode, which can then be run in a little interpreter written in JS. The goal of the experiment is to try to improve startup times by moving less-important code into the bytecode (which doesn't need to be parsed by the JS engine, which often is a big factor in page startup), of course the downside is it runs more slowly there. Experimentation is still in progress, but most of the test suite can already run in the interpreter, and early numbers seem promising, at least for some types of use cases: The emterpreter is slow as you would expect, but also improves startup time, and you can run just some of the code in the slow mode, making it worthwhile overall.

Another potential use of the emterpreter is emulation of tricky features like synchronous calls,  longjmps up the stack (which is undefined behavior), etc., because in the interpreter we can manually control the call stack. The speed penalty can be severe, though, so this won't help performance-intensive applications, but it might be interesting to experiment with. If anyone is interested, let me know (I am focusing mostly on the first use, of improving startup speed).

When the emterpreter is more ready I'll probably write up a blogpost. Meanwhile you can try it with e.g.

./emcc -O1 tests/hello_world_loop.cpp -s EMTERPRETIFY=1 --memory-init-file 1

then look in a.out.js, and you can see

function _main() {
 emterpret_z(2560);
 return HEAP32[EMTSTACKTOP >> 2] | 0;
}

Basically main() has been replaced by a call into the emterpreter, telling it to run code at address 2560. You can also see that other methods do not run in the emterpreter, like memset; this approach lets you choose exactly which methods run in which mode.

- Alon

[caiiiycuk]

Hi Alon. Can i use emterpreter to avoid problems related to infinite loops. For example i have game that mostly emscripten ready, but some functions contains infinite loops that can't be easily rewritten.

void infinite() {
  while (true) {
     // ...
     while (true) {
       // ..
       if (something) break;
     }
    if (something2) break; 
  }
}

Can i use emterpreter only for function infinite and after that it will work fine in browser?

[Alon Zakai]

The emterpreter doesn't do that yet, but it could definitely be extended to allow that. If there is nothing below that on the stack, then you could run just that in the emterpreter, and run all the rest of the code normally, so the project overall wouldn't be slow. And in the emterpreter we would pause and resume it across browser event loops.

Good to know this would be useful, I'll try to get to it soon.

- 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 emscripten-disc...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Александр Гурьянов]

I think it is will be useful feature. Usually native code has not important functions that cannot be easily ported, for example playing videos between game levels or video/sound effects such as fadeout and fadein usually implemented as uninterrupted loop. For simplicity i just disable this effects, but if emterpreter can do this in asynchronous manner it will be great.

But it is not critical to have this feature right now. For me this feature can be delayed for sometime if it can`t be easily implemented.

--

С уважением, Гурьянов Александр