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