Wondering if you've gotten any further answering the question you pose below? I also am interested in being able to generate a JVM backend, but not departing, as you are, from coding in java itself, but rather as a means to integrate my own custom vm with Java and be able to produce and consume java code easily from my custom environment. Just curios if you made any progress answering this question for yourself and the final one you pose: "Is LLVM for me?" Sorry if I'm repeating something that was already said. I was just thinking "why the heck do I seem headed for JVM generation if what I want to use is LLVM", and this is the result: I'm coming from a Java background. I'm using Eclipse, I'm used to the syntax highlighting, cross referencing and refactoring support that Eclipse offers. I know I will want to have the same infrastructure for my language, and I want it written in my language. I WILL need a JVM backend, no matter what. Now, I'd still love to use LLVM. It has a lot to offer for the phases "above" code generation. I don't need register allocation, but I'd like to make use of common constant elimination, loop unrolling, inlining, or the pass management infrastructure; that's a whole lot of code I don't need to write. And when it comes to generating raw machine code, I can confidently say: develop in Eclipse and run the stuff as JVM code, but deploy using the machine-code backend provided by LLVM. So my conclusion is: To make LLVM attractive for us Java-based language designers, we need the means to write a JVM backend. The actual backend is easy, libraries for class file and JAR generation exist. I'd need help for: * Determining where exactly the line is drawn between "this LLVM component is useful for JVM bytecode generation" and "this LLVM component isnt". (Constant folding would be, register allocation would not, but there's a lot of gray areas between these two.) * Not being a JNI or C++ expert, building the JNI infrastructure that would allow calling LLVM components from Java. * Not being a true Eclipse expert, wrapping LLVM binaries as Eclipse plugins. Eclipse expects plugins to be available for download via HTTP, with some XML that describes dependencies. Setting this up would be easy, getting the details right would be work. That's just my specific skillset, other language designers might have different ones, but I guess it is not very likely that the exact right combination will come up easily. There aren't many people around who're experts in C++, Java, and Eclipse. Oh, and the question I'm having is: Is LLVM for me? Regards, Jo -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111007/772b1cfe/attachment.html>
On Oct 7, 2011, at 7:42 AM, Michael Clagett wrote:> Wondering if you've gotten any further answering the question you pose below? > > I also am interested in being able to generate a JVM backend, but not departing, as you are, from coding in java itself, but rather as a means to integrate my own custom vm with Java and be able to produce and consume java code easily from my custom environment.LLVM doesn't produce Java code today, and it isn't especially well suited for this.> > Just curios if you made any progress answering this question for yourself and the final one you pose: "Is LLVM for me?"The answer to "Is LLVM for me?" depends on what you're looking to do. In your case, we have few details to go on here, but it sounds like you're already pretty Java-oriented, so sticking with Java might be a good idea. Responding to the earlier email:> Sorry if I'm repeating something that was already said. > > I was just thinking "why the heck do I seem headed for JVM generation if > what I want to use is LLVM", and this is the result: > > I'm coming from a Java background. I'm using Eclipse, I'm used to the > syntax highlighting, cross referencing and refactoring support that > Eclipse offers. > I know I will want to have the same infrastructure for my language, and > I want it written in my language. I WILL need a JVM backend, no matter what. > > Now, I'd still love to use LLVM. It has a lot to offer for the phases > "above" code generation. I don't need register allocation, but I'd like > to make use of common constant elimination, loop unrolling, inlining, or > the pass management infrastructure; that's a whole lot of code I don't > need to write. > And when it comes to generating raw machine code, I can confidently say: > develop in Eclipse and run the stuff as JVM code, but deploy using the > machine-code backend provided by LLVM.If you're looking for a way to develop in Java and then compile to native code, consider the many Java-to-native-code compilers out there. Many of them include optimizations like loop unrolling and inlining. LLVM is probably not the best tool here.> > So my conclusion is: > To make LLVM attractive for us Java-based language designers, we need > the means to write a JVM backend.Translating from Java to LLVM IR and then back to Java would probably not be very practical. If you're a "Java-based language designer" to begin with, and you want to run your programs in the JVM, it's probably best to just stick with Java the whole way. Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111007/1a71d193/attachment.html>
Am 07.10.2011 19:28, schrieb Dan Gohman:> Translating from Java to LLVM IR and then back to Java would > probably not be very practical.That's not what I'm aiming for. I want MyHLL -> MyCompiler -> MyIR1 -> MyTransformer -> MyIR2 -> Backend Where "Backend" could be a code generator for the JVM, CLR, or something LLVM-based. It would be nice if I could have ... -> MyIR2 -> LLVM -> JVM/CLR/native since that would take some passes out of MyTransformer. I'm not sure how useful LLVM would be in such a scenario. Essentially, my question is how much I can leverage out of LLVM (with the usual caveats, of course - being more like Haskell than C++, I guess LLVM isn't built for that, but it might still be worth it).> If you're a "Java-based language designer" to begin with, and you > want to run your programs in the JVM, it's probably best to just > stick with Java the whole way.I'm "Java-based" only in terms of tooling. Eclipse is just a ready-made framework that many people know and has a lots of ready-made facilities that I don't need to build on my own: syntax-aware editor, cross-referencing, debugging. Actually, the JVM has some limitations that make it less well-suited than I'd like, but tooling trumps that. In that scenario, a JVM backend for LLVM would be helpful - assuming LLVM can do anything helpful in that situation. (It's just occurring to me that code reordering might make LLVM-generated JVM bytecode harder to debug.) Regards, Jo