The JIT compiler is of course of great interest, but I'm also interested in static compilation and in fact this seems to me one of the intriguing features of LLVM, the fact that it can support both static and dynamic languages, with a common optimization infrastructure. (I want my cake and to eat it too.) If I wanted just static compilation I could emit C as well, or if I just wanted a JIT compiler I could emit the .NET CLR or Java bytecodes. Just as an aside, how do you support tail calls or more general functional language paradigms with your C backend? What if I don't ever want to use a call stack for my function arguments, for example?
Pardon me for my woeful ignorance, but currently I presume that on Linux using an X86 CPU you can emit either object code directly or some kind of intermediate ASCII assembly code? If that is the case, then apparently the only problem is operating system specific calls in the backend of the LLVM compiler. Also I presume that the JIT compiler really is a JIT compiler and compiles genuine machine readable object code for an x86 processor (among others), that is executed in memory ; as opposed to compiling byte code that is ultimately just interpreted.
I suppose therefore that I would be interested in Henrik's notes, at the very least to see how deep the rabbit hole goes, so to speak. It would be at least 2 weeks before I would be able to dig into this in earnest however.
-Matt
It is the goal to generate OBJ files directly, though that is not likely to happen in the near future. But there are other options that do work today. The JIT does work, so you can execute programs compiled via LLVM right now. Additionally, you can generate C code that you can then compile with VC++, which provides an alternate route to stand-alone executables.
The JIT compiler is of course of great interest, but I'm also interested in static compilation and in fact this seems to me one of the intriguing features of LLVM, the fact that it can support both static and dynamic languages, with a common optimization infrastructure. (I want my cake and to eat it too.)
Sure.
If I wanted just static compilation I could emit C as well, or if I just wanted a JIT compiler I could emit the .NET CLR or Java bytecodes. Just as an aside, how do you support tail calls or more general functional language paradigms with your C backend? What if I don't ever want to use a call stack for my function arguments, for example?
Not well. It depends on the C compiler to implement these, which means it probably won't happen.
Pardon me for my woeful ignorance, but currently I presume that on Linux using an X86 CPU you can emit either object code directly or some kind of intermediate ASCII assembly code? If that is the case, then apparently the only problem is operating system specific calls in the backend of the LLVM compiler. Also I presume that the JIT compiler really is a JIT compiler and compiles genuine machine readable object code for an x86 processor (among others), that is executed in memory ; as opposed to compiling byte code that is ultimately just interpreted.
Actually it is much simpler than that. If you are willing to install 'gas' on your windows box (part of cygwin, for example), you can use our native backend, with tail calls etc. Being able to emit windows .o files directly only eliminates the need to have gas installed.
I suppose therefore that I would be interested in Henrik's notes, at the very least to see how deep the rabbit hole goes, so to speak. It would be at least 2 weeks before I would be able to dig into this in earnest however.
Great, help is certainly appreciated!
-Chris
Chris Lattner wrote:
Actually it is much simpler than that. If you are willing to install 'gas' on your windows box (part of cygwin, for example), you can use our native backend, with tail calls etc. Being able to emit windows .o files directly only eliminates the need to have gas installed.
Well, the theory is that if you're using VC++, you do not have the GNU tool chain installed nor are you particularly interested in installing it. Also, Windows doesn't have .o files; it has .obj files 
I stand corrected. My only point was that LLVM is not useless on win32. Yes, it could be better and hopefully will in the future, but it is not true that the only option is to use the JIT.
-Chris
From: Matthew Bromberg <mattcbro@earthlink.net>
Date: Tue, 01 Nov 2005 16:21:34 -0500
The JIT compiler is of course of great interest, but I'm also interested in static compilation and in fact this seems to me one of the intriguing features of LLVM, the fact that it can support both static and dynamic languages, with a common optimization infrastructure. (I want my cake and to eat it too.) If I wanted just static compilation I could emit C as well, or if I just wanted a JIT compiler I could emit the .NET CLR or Java bytecodes. Just as an aside, how do you support tail calls or more general functional language paradigms with your C backend? What if I don't ever want to use a call stack for my function arguments, for example?
Pardon me for my woeful ignorance, but currently I presume that on Linux using an X86 CPU you can emit either object code directly or some kind of intermediate ASCII assembly code? If that is the case, then apparently the only problem is operating system specific calls in the backend of the LLVM compiler. Also I presume that the JIT compiler really is a JIT compiler and compiles genuine machine readable object code for an x86 processor (among others), that is executed in memory ; as opposed to compiling byte code that is ultimately just interpreted.
I suppose therefore that I would be interested in Henrik's notes, at the very least to see how deep the rabbit hole goes, so to speak. It would be at least 2 weeks before I would be able to dig into this in earnest however.
You're welcome to join me. Say when you're ready to dig...
Henrik.
You're welcome to join me. Say when you're ready to dig...
I'll join in at some point, if that is okay.
I'd like to get LLVM working on MinGW running as well as Cygwin.
Aaron
From: "Aaron Gray" <angray@beeb.net>
Date: Fri, 4 Nov 2005 16:44:23 -0000
You're welcome to join me. Say when you're ready to dig...
I'll join in at some point, if that is okay.
I'd like to get LLVM working on MinGW running as well as Cygwin.
Sure, I would love to have you on the team, too, so we can get llvm via this MinGW/Windows thing on the right track... and get it out to the unknowing masses
Henrik.
You're welcome to join me. Say when you're ready to dig...
I'll join in at some point, if that is okay.
I'd like to get LLVM working on MinGW running as well as Cygwin.
Sure, I would love to have you on the team, too, so we can get llvm via this MinGW/Windows thing on the right track... and get it out to the unknowing masses
Cheers Henrik. Will have to get a stable MinGW environment set up.
I'll get back in touch when Mathew picks thing up.
Aaron