[LLVMdev] JVM Backend

[David Roberts]

> If you translate to a big array of memory and index into it, how is it
> better than the mips -> java compiler?
Yes, it is similar to the mips to java compiler in that regard, but it
does have several advantages over it. For example, functions are
mapped to individual methods (rather than just a big chunk of
translated instructions), allowing Java to call individual functions
in the compiled language and vice versa. This also allows programs to
be split amongst multiple classes rather than statically linking
everything into the one file (which is sometimes not possible for
large projects).

>> If this patch is not to be included in the LLVM source tree, then is
>> it possible to distribute backends as standalone tools?
>
> Sure, you can use 'llc -load foo.so' to dynamically load backends.
Ok, I might do that then. Thanks for your time :)

--
David Roberts
http://da.vidr.cc/



On Fri, Nov 27, 2009 at 15:27, Chris Lattner <clattner at apple.com> wrote:
> On Nov 26, 2009, at 4:57 PM, David Roberts wrote:
>>> Who is the expected client of this code?
>> There are several reasons why compiling to JVM bytecode can be
>> desirable. For example, it can be executed on platforms that do not
>> support native code execution for security or other reasons e.g.
>> browser applets, mobile devices, some webhosts. From the Java
>> perspective, it allows libraries written in languages such as C to be
>> used in a cross-platform manner, without the need for reliance on a
>> native library through JNI.
>
> That's all fine, if it actually works.  Supporting the full generality of LLVM IR is imperative if you want to achieve that goal, and I'm not sure how you do that.
>
>>> Will it be maintained going forward?
>> I can't guarantee anything, but I'll do my best to keep it maintained.
>>
>>> Is it going to cover the full generality of LLVM IR constructs?
>>> How do you plan to handle unsafe IR?
>> Sorry, I'm still relatively new to LLVM, so I'm not sure what you're
>> refering to.
>
> How does your code handle non-type-safe C code?  How does it translate it to type-safe java code?  If you translate to a big array of memory and index into it, how is it better than the mips -> java compiler?
>
>> If this patch is not to be included in the LLVM source tree, then is
>> it possible to distribute backends as standalone tools?
>
> Sure, you can use 'llc -load foo.so' to dynamically load backends.
>
> -Chris