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
On Oct 2, 2010, at 8:11 PM, David LaPalomento wrote:> 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.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 On Sun, Oct 3, 2010 at 2:21 AM, Owen Anderson <resistor at mac.com> wrote:> > On Oct 2, 2010, at 8:11 PM, David LaPalomento wrote: > >> 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. > > How does this compare to Empscripten? http://code.google.com/p/emscripten/ > > --Owen > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >
> 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 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