Your question about LLVM

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

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

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

To get an idea of the feasibility of translating LLVM IR to Java or CLR,
look at existing C to Java translators. An LLVM IR to Java translator
would face most of the same challenges, as well as some new challanges.

Dan