> 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.> 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. If this patch is not to be included in the LLVM source tree, then is it possible to distribute backends as standalone tools? -- David Roberts http://da.vidr.cc/ On Fri, Nov 27, 2009 at 07:47, Chris Lattner <clattner at apple.com> wrote:> > On Nov 26, 2009, at 12:14 AM, David Roberts wrote: > >>>> Additional patch attached, is this suitable? >>> Looks good, thanks. What's about arithmetics? >> Revised patch attached. > > Hi David, > > I'm not very excited about this patch. We already have a C backend and MSIL backend. Neither of those support the full generality of LLVM IR (for example, exceptions, 'weird' integers, etc) and therefore aren't reliable. I don't know of anyone using the MSIL backend and it continues to bit rot. IMO, the MSIL backend should just be removed. > > Who is the expected client of this code? Will it be maintained going forward? Is it going to cover the full generality of LLVM IR constructs? How do you plan to handle unsafe IR? > > -Chris > >> >> -- >> David Roberts >> http://da.vidr.cc/ >> >> >> >> On Thu, Nov 26, 2009 at 17:08, Anton Korobeynikov >> <anton at korobeynikov.info> wrote: >>> Hello, David >>> >>>> Additional patch attached, is this suitable? >>> Looks good, thanks. What's about arithmetics? >>> >>>>> The current big question is: how you're planning to deal with >>>>> arbitrary precision stuff which might come from LLVM IR. >>>> I should be able to implement that. Would arbitrary precision support >>>> be required for the initial commit of the backend? >>> I really don't think so. But you should aware, that you can easy >>> obtain, say, i33 from C bitfields-heavy code, or i256 due to LLVM >>> optimizers. >>> >>> -- >>> With best regards, Anton Korobeynikov >>> Faculty of Mathematics and Mechanics, Saint Petersburg State University >>> >> <llvm-jvm-test.patch.gz> > >
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
> 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