search for: vidr

...et this commited - I'm quite happy to keep it as a separate project. I've cleaned up the code a bit and released it as part of LLJVM[1], so any fixes to the problems people have highlighted in this thread will be pushed to the repository listed on that page as I get to them. [1] http://da.vidr.cc/projects/lljvm/ -- David Roberts http://da.vidr.cc/ On Mon, Nov 30, 2009 at 19:39, Renato Golin <rengolin at systemcall.org> wrote: > 2009/11/30 David Roberts <d at vidr.cc>: >>> Nobody is asking for perfection, just completeness. >> I'd just like to point o...

2009/11/30 David Roberts <d at vidr.cc>: >> Nobody is asking for perfection, just completeness. > I'd just like to point out that I don't have a great deal of > experience in compiler development - I just thought that this would be > an interesting project to try. I realise that it isn't complete in >...

...g for perfection, just completeness. I'd just like to point out that I don't have a great deal of experience in compiler development - I just thought that this would be an interesting project to try. I realise that it isn't complete in it's current state. -- David Roberts http://da.vidr.cc/ On Mon, Nov 30, 2009 at 04:46, Jon Harrop <jon at ffconsultancy.com> wrote: > On Sunday 29 November 2009 02:06:04 you wrote: >> > So it will stack overflow on tail calls >> >> At the moment, yes. But then again, so does java. > > Sure but a lot of people l...

>> Additional patch attached, is this suitable? > Looks good, thanks. What's about arithmetics? Revised patch attached. -- 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 planni...

...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? >> >>>>...

...nstructs? > 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 pa...

...andard Library. Before I go reinventing the wheel, has anyone had any luck with compiling a libc implementation (e.g. newlib) to LLVM IR (without any platform-dependent inline assembly, etc)? What is the process for requesting this patch be applied to the LLVM source tree? [1] Homepage: http://da.vidr.cc/projects/lljvm/ Download: http://lljvm.googlecode.com/files/lljvm-0.1.jar [2] http://jasmin.sf.net/ -- David Roberts http://da.vidr.cc/ -------------- next part -------------- A non-text attachment was scrubbed... Name: llvm-jvm.patch.gz Type: application/x-gzip Size: 13136 bytes Desc: not...

...Currently all > the things seems to behave different in case of receiving e.g. i31: > - functions like getTypeName() return some junk (the case > Type::IntegerTypeID just falls through to Type::FloatTyID) getBitWidth raises an assertion before this can happen. -- David Roberts http://da.vidr.cc/ On Wed, Nov 25, 2009 at 21:03, Anton Korobeynikov <anton at korobeynikov.info> wrote: > Hello, David > > First of all, thanks for the backend submission. I let Chris comment > about the procedure of adding it to the tree. :) > > I just did a quick look into the code....

...t; 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 examp...

...orried 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? >&gt...

...ds any fully working solution rather > than a selection of incomplete solutions. I haven't been working on this project for too long - you can't expect it to be perfect on the first release. [1] http://openjdk.java.net/projects/mlvm/subprojects.html#TailCalls -- David Roberts http://da.vidr.cc/ On Sun, Nov 29, 2009 at 09:49, Jon Harrop <jon at ffconsultancy.com> wrote: > On Saturday 28 November 2009 06:20:39 David Roberts wrote: >> > How do you handle tail calls and value types? >> >> I haven't worried too much about optimisation yet, so it doesn...

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

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

Hi David, > No, structs are supported. The only unsupported types at the moment > (as far as I am aware) are things like i31 and f80. for funky sized integers, the most important operations to support are loads and stores, shifts and logical operations (and, or, xor). These are the ones that the optimizers like to introduce most. The logical operations are straightforward. Loads and

On Saturday 28 November 2009 06:20:39 David Roberts wrote: > > 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

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

Hello, David First of all, thanks for the backend submission. I let Chris comment about the procedure of adding it to the tree. :) I just did a quick look into the code. The comments are below > Indirect function calls don't work yet, and there's probably some > minor bugs in it, but it works well for the test cases that I've run > through it. Could you please provide some

On Sunday 29 November 2009 02:06:04 you wrote: > > So it will stack overflow on tail calls > > At the moment, yes. But then again, so does java. Sure but a lot of people like me are using LLVM precisely because it offers these wonderful features. As long as your JVM backend does not handle these features correctly its utility is greatly diminished. > Also, it looks like

Hey lists, This is somewhat OT, but just a little. I want to capture live (5 fps?) 1024x768 VGA and make mpeg or something I can stream over the net. The application is this: Developer meetings and conferences. "all" speakers bring their laptops and hook up to the 1024x768 projector. I want to broadcast that over the net. (I may point a web cam at the presenter too and have