I've done this --- see: http://cluecc.sourceforge.net/ http://cluecc.sourceforge.net/ It compiles C89 C into Java, Javascript, Lua, Perl and Common Lisp. Poin

I've done this --- see: http://cluecc.sourceforge.net/ http://cluecc.sourceforge.net/ It compiles C89 C into Java, Javascript, Lua, Perl and Common Lisp. Pointers are represented as an array pointing at the object and an offset into the array, so sizeof(void * ) == 2 and sizeof(everything else) == 1. This allows efficient pointer arithmetic while still using one native allocation per object. It relies heavily on C89 undefined behaviour. Alas, C99 adds (IIRC) a defined mapping from an object to bytes and vice versa, which means this approach won't work. Also, the compiler frontend I was using, sparse, had bugs where it would try to convert a pointer to an int, do arithmetic, and then convert back again. So it's not suitable for real work. Performance was better than I was expecting it would run C on Java at 1/3 the speed of native. That's pretty good for a naive toy. Running C on LuaJIT was amazing; very nearly the same speed as native. (For a set of artificial, non-representative benchmarks.) Java, Javascript and Lisp are all crippled by not having goto. goto allows you to express arbitrary basic block graphs, which C supports. Without it, I have to use a big switch statement inside a while loop --- JITs hate this. Emscripten gets around this by using algorithms to try and represent the basic block graph as much as possible with structured control flow statements, but this can't work in all situations, so it has to fall back to the explicit state machine if that doesn't work. Which is, of course, slow. LuaJIT does support goto. When I converted from Lua 5.1 (with no goto) to LuaJIT, I estimated about a 30% speed improvement. Languages without goto statements are toys, dammit...