Hi, I'm one of the main authors of Browsix. One of our goals is to run C code - we have simple utilities from sbase running, and more complex code like latex and GNU make (the README needs updating). The main complication is that C code does system calls, which are traditionally blocking, and there isn't a good way to achieve that in current browsers with just ASM.js. So, we currently use the Emterpreter[1] (which is much slower) to make sure that anything on the stack underneath a system call can be saved and restored. SharedArrayBuffers should let us implement something faster in the near future.
Interesting. Normal javascript has a "yield" directive, but I guess that it is not part of ASM.js. Is this something that ASM.js will eventually support?
Also, is Emterpreter really an interpreter, or do they still compile parts of the code to ASM.js for performance (e.g., parts that do not contain system calls)?
The emterpreter is really an interpreter, but as you guessed, you can direct the compiler to compile parts of your code to ASM.js so that you can benefit from native-like performance for CPU-intensive parts of your app.
Yield is relatively new, part of ES6, and I think is tied into async/await. It might be possible to use it in combination with something like Babel, but I didn't go down that route. I think the way forward is SharedArrayBuffers and their blocking wait()s on futexes.
My (limited) understanding is that asm.js doesn't allow blocking code, which means it's not a good fit for a Posix like model with a main function which calls out to external services. (I'd love to be wrong here.)
I hear that there's a plan for some form of limited shared-memory concurrency which might be abusable to allow threads, but I haven't made much of the designs.
My point: JavaScript, it's ecosystem and community are bad enough to be proprietary. It's the new skurge of the web browser and what do people do? Make 'applications' with it.
1 - https://github.com/kripken/emscripten/wiki/Emterpreter