similar to: [LLVMdev] llvm "iword" type

Small nitpick: size_t is not guaranteed to be large enough to hold a pointer (only an array index, which can be less; though such platforms are pretty exotic now). [u]intptr_t are the types. Eugene On Mon, Aug 9, 2010 at 5:44 PM, Joshua Warner <joshuawarner32 at gmail.com> wrote: > Hi, > > I'm generating some LLVM IR that has to mask out the lower bits two bits of > a

That and the possibility of differently sized pointers made me hesitate to dive into implementing this. I guess nailing it down to be the platform equivalent of size_t would be sensible here. On Mon, Aug 9, 2010 at 1:37 PM, Eugene Toder <eltoder at gmail.com> wrote: > Small nitpick: size_t is not guaranteed to be large enough to hold a > pointer (only an array index, which can be

I looked through the "intp" thread. I don't really want to start that argument up again, but my immediate thought would be to create a new class of "picked-by-the-target" integer types (equivelents of size_t, intptr_t, etc...), and two new instructions, zcast and scast, which are only valid in the context of casting to / from integer types of unknown sizes. To begin with,

On Mon, Aug 9, 2010 at 4:08 PM, Kenneth Uildriks <kennethuil at gmail.com> wrote: > On Mon, Aug 9, 2010 at 4:02 PM, Joshua Warner <joshuawarner32 at gmail.com> wrote: >> >> >> On Mon, Aug 9, 2010 at 1:51 PM, Kenneth Uildriks <kennethuil at gmail.com> >> wrote: >>> >>> On Mon, Aug 9, 2010 at 2:43 PM, Joshua Warner <joshuawarner32 at

Hi Nicolas, Thanks for all your help, but if 64-bit systems are still a big problem, perhaps the VMKit AOT compiler is not the best solution to my problem. I'd like to be able to support the major (if not all all) platforms that the Avian JVM supports - x86 & x86_64 linux & windows, powerpc darwin and ARM. Regards, Joshua On Tue, Jul 20, 2010 at 8:00 AM, nicolas geoffray <

Hi Minas, I tried recompiling Classpath with -fno-omit-frame-pointer, and now, instead of printing an error message, j3 just segfaults in "j3::JnjvmClassLoader::loadClassFromAsciiz(char const*, bool, bool) ()" I ran llcj under strace and found that it is not even opening the input or output files, but is otherwise running normally. Updating to the latest SVN version (revision 108831)

Forgot to send to the mailing list... ---------- Forwarded message ---------- From: Joshua Warner <joshuawarner32 at gmail.com> Date: Mon, Jul 19, 2010 at 10:19 AM Subject: Re: [LLVMdev] Building VMKit To: nicolas geoffray <nicolas.geoffray at gmail.com> Thanks Nicolas, that worked great! Now, I'm having trouble invoking the compiler properly: $ llcj Hello.class -o=Hello.ll $

Hi Nicolas, I plan on using the Avian GC (which is a precise, generational collector). Eventually, I'd like to fully integrate all of the runtime services Avian provides - even integrating the existing Avian JIT compiler, to allow for partially-AOT builds. Avian does indeed have it's own class library, but I would be very surprised if VMKit could compile with them - they are sufficiently

Sure: I'm on 64-bit Ubuntu Linux 10.04 with gcc 4.4.3. I followed the instructions on http://vmkit.llvm.org/get_started.html, as near as I can tell. I configured llvm with the default configuration: ./configure I configured vmkit with: ./configure --with-llvmsrc=/home/jowarner/code/llvm/ --with-llvmobj=/home/jowarner/code/llvm/ --with-gnu-classpath-glibj=/usr/share/classpath/glibj.zip

On Tue, Jul 20, 2010 at 9:52 AM, nicolas geoffray < nicolas.geoffray at gmail.com> wrote: > On Tue, Jul 20, 2010 at 5:35 PM, Joshua Warner <joshuawarner32 at gmail.com>wrote: > >> Hi Nicolas, >> >> I plan on using the Avian GC (which is a precise, generational >> collector). >> > > OK - Great! > > >> Eventually, I'd like to

Hi Joshua, What plans did you have for GC? No GC at all or Avian JVM has its own GC (and is it precise or not?)? If you're not planning on using VMKit's GCs, then 64-bit system should not be a big problem: the only problem that we have now is compiling GNU Classpath, and most probably Avian JVM has its own version of the class libraries? Also, note that platform support will be strongly

Hi Joshua, If you can get a running 32bit system, I'd suggest you do so, as you'll get up to speed right away. I can't test VMKit on a 64bits machine, and I have been aware that there are some compilation/execution problems. Besides, the current GCs of VMKit do not work on 64bits (neither MMTk nor GCMmap2). Nicolas On Tue, Jul 20, 2010 at 3:56 PM, Joshua Warner <joshuawarner32 at

Hi James, I see the problem now. You might look at VMKit (a Java VM build with the LLVM JIT compiler) - I would expect it uses a similar method for resolving interface calls (the method, if I understand it correctly, is well-known in the Java world). I've CC'd the main dev behind VMKit - he might be able to lend some insight. --Joshua On Mon, Jan 31, 2011 at 2:24 PM, James Williams

On Tue, Jul 20, 2010 at 5:35 PM, Joshua Warner <joshuawarner32 at gmail.com>wrote: > Hi Nicolas, > > I plan on using the Avian GC (which is a precise, generational collector). > OK - Great! > Eventually, I'd like to fully integrate all of the runtime services Avian > provides - even integrating the existing Avian JIT compiler, to allow for > partially-AOT

Thanks, that's a good idea - I'll have a look through the VMKit source. -- James On 31 January 2011 21:39, Joshua Warner <joshuawarner32 at gmail.com> wrote: > Hi James, > > I see the problem now. You might look at VMKit (a Java VM build with the > LLVM JIT compiler) - I would expect it uses a similar method for resolving > interface calls (the method, if I

Hi Joshua, > $ j3 Hello > j3: JavaClass.cpp:480: j3::JavaObject* j3::Class::doNew(j3::Jnjvm*): > Assertion `(this->isInitializing() || > classLoader->getCompiler()->isStaticCompiling()) && "Uninitialized class > when allocating."' failed. > Aborted Regarding to j3 in 64 bit version, it should work now after we've found crush reason, both in

On Tue, Jul 20, 2010 at 6:36 PM, Joshua Warner <joshuawarner32 at gmail.com>wrote: > Sure, that's one major strength of LLVM: we could decide on a runtime >> function (CallVirtualMethod) that will get lowered depending on the >> underlying VM. I don't see any difficulties in accomplishing this. >> > > Is it common practice to emit function calls that are

Hi Minas, Thanks! I wasn't aware that VMKit had the ability to generate llvm code from .class / .jar files - I thought all of its code-generation capabilities were very closely tied to the VM itself. I'll look into this. The motivation behind this project is to be able to get both the small size and fast startup times of Avian, along with the speed of llvm-generated code. Currently,

Forgot to cc the list. > >----- Forwarded Message ---- >From: Samuel Crow <samuraileumas at yahoo.com> >To: James Williams <junk at giantblob.com> >Sent: Mon, January 31, 2011 4:27:45 PM >Subject: Re: [LLVMdev] Compile function with limited set of registers? Jump to >another function? > > >Hi James, > > >If you're looking for a way to

Hi James, Joshua is right, what you're trying to accomplish is quite known in the Java VM world ( http://domino.research.ibm.com/comm/research_people.nsf/pages/dgrove.oopsla01.html ). In order to express the "thunk" code in LLVM you need a full control of how registers are used (because otherwise they would mess up with the arguments). I haven't investigated enough to know if