JavaScript Backend

Hi all,
Over the past couple weeks, I've been putting together a JavaScript
backend for LLVM. At this point, I believe I've got reasonable
implementations for all the instructions, primitives and derived
types. I haven't gotten around to most of the intrinsics but I thought
it would be a good idea to start getting some feedback before going
much further. If anyone has the time and interest to check it out, the
repo is up at http://github.com/dmlap/llvm-js-backend.

What I'm missing is a good understanding of what IR features language
developers are using that have to be implemented to make the
JavaScript backend a viable target. Any suggestions or pointers would
be greatly appreciated!

David

How does this compare to Empscripten? http://code.google.com/p/emscripten/

--Owen

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

How does this compare to Empscripten? http://code.google.com/p/emscripten/

Looks like this one is a backend of LLVM, whereas Empscripten is a bitcode
translator that doesn't touch LLVM.

Marcus

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