[LLVMdev] JavaScript Backend

[Alon Zakai]

Yeah, the goals are very similar, while the
implementations are quite different. llvm-js-backend
is an LLVM backend, while Emscripten is written in JS.

There are advantages to both approaches. A proper
backend will integrate better with LLVM, naturally,
which has obvious benefits. Emscripten's goal on the
other hand is to integrate better into the web. For
example, in Emscripten the code that generates a
'C structure' (that can be processed by the compiled
code) is written in JS, so it can be run by both the
Emscripten compiler at compile time, and by JS code
on the web. That can be useful to integrate regular
web scripts with compiled code.

(The other main reason for Emscripten being in JS is
that a lot of code is needed for things like
reconstruction of high-level (JS) loop structure from
low-level (LLVM bitcode) branching, etc., and I
personally find it more convenient to try different
approaches quickly in a dynamic language.)

Regarding sharing test code, definitely we should do
that. Aside from tests for individual LLVM features,
Emscripten's tests include some benchmarks and also
real-world code: dlmalloc (a popular malloc
implementation in C), a ray tracer, and a complete
script engine (CubeScript, in C++). Maybe those
can be useful for you in llvm-js-backend to see what
LLVM features are important - Emscripten's test
runner passes those through both Clang and llvm-gcc,
so you can see what LLVM features are generated by
those (the two are different in some ways).

- azakai


On Oct 3, 2010, at 10:26 AM, David LaPalomento wrote:

> Short answer: they're very similar. They both translate LLVM IR into
> javascript, though there are some significant differences in how we've
> gone about that. emscripten has its own stand-alone IR parser written
> in javascript while I opted to do the translation as a regular backend
> in the LLVM source tree, similar to the C backend. I contacted Alon
> Zakai (emscripten's developer) before posting to this list and while
> it doesn't look like a direct merge of the two projects is possible,
> we're looking for ways to share some code and test cases. I'm not
> familiar enough with emscripten to know which project is further along
> at this point.
> 
> My ultimate goal in starting this was to give any language hosted on
> LLVM the option to compile to the browser. I do a solid amount of web
> app development myself and I must admit to being a bit jealous of the
> javascript-on-the-server/Node.js crowd. Being able to share your
> client and server-side codebase is a big win for application
> developers and it seemed that targeting a shared language platform
> like LLVM would open up that possibility for a lot of people. I chose
> to implement it as a backend because I felt that having that
> capability one day folded into LLVM proper would open it up to the
> largest audience. It's still a ways off from that, certainly, but
> that's the direction I'd like to head in.
> 
> David