llvm dev - Nov 2009 - [LLVMdev] JVM Backend

> 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

On Friday 27 November 2009 05:55:59 David Roberts wrote:
> > 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).
How do you handle tail calls and value types?

-- 
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e

> How do you handle tail calls and value types?
I haven't worried too much about optimisation yet, so it doesn't do
anything special for tail calls (although neither does the java
compiler). LLVM types are translated to their equivalent java
primitive type (or currently it raises an assertion if there is no
equivalent type).

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



On Sat, Nov 28, 2009 at 02:56, Jon Harrop <jon at ffconsultancy.com>
wrote:
> On Friday 27 November 2009 05:55:59 David Roberts wrote:
>> > 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).
>
> How do you handle tail calls and value types?
>
> --
> Dr Jon Harrop, Flying Frog Consultancy Ltd.
> http://www.ffconsultancy.com/?e
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>