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