Re: [LLVMdev] Re: LLVM and PyPy
Hi Chris, [Chris Lattner Fri, Oct 31, 2003 at 10:58:45AM -0600]
On Fri, 31 Oct 2003, Armin Rigo & Holger Krekel wrote:
Hello Chris,
We have been investigating your project and the good documentation and are very impressed. If we understood your goals correctly this seems like a good match for our ongoing and active PyPy project, a reimplementation of the Python language in Python.
Cool. We are all big fans of Python here. :)
That's good because we might want to recode some LLVM functionalities in Python :-)
We'll definitely try using LLVM as our low-level backend. But actually we contact you now to ask you if you'd be interested in some bidirectional collaboration.
I've read up a bit on PyPy, and it looks like LLVM could be a nice way to get the JIT type interface that you would like. Also, making use of the LLVM optimizer can make your staticly generated code nice and fast. :)
Yes, but we also would want to dynamically emit and execute LLVM code. But a static translation is indeed our first goal :-)
We've tossed around the idea of creating C bindings for LLVM, which would make interfacing from other languages easier than going directly to the C++ API, but we just haven't had a chance to yet. Maybe you guys would be interested in helping with that project?
Thinking some more about it, we would probably try to translate our PyPy implementation into LLVM-code and also generate some glue-LLVM-code which allows us to programmatically drive LLVM from Python. Is LLVM able to "drive" itself? I mean can the LLVM-low-level object code generate LLVM-low-level object code and then execute it? This would fit nicely with PyPy because we are running ourselves (in 'abstract interpretation' mode) in order to generate a low-level representation of ourselves. This low-level representation is already close to LLVM's low-level view. So if the LLVM-code gets executed (beeing a python interpreter) it should be able to just-in-time-compile new LLVM code and execute it. With our architecture, for such a JIT we could reuse a good part of the code we already have for generating our low-level representation. It's a rather self-referential thing (also see our logo: http://codespeak.net/pypy/ :-).
On another level, some of the PyPy core developers are actually also involved with the 'codespeak' site which aims at connecting interesting open source projects and provide new collaborative development services. The PyPy project is extensively using subversion which is a very interesting (and stable) alternative to cvs. So if you need any help with setting up some publically accessible infrastructure the codespeak guys will certainly welcome you.
At this point, we're working like crazy to get important features implemented in LLVM. We certainly acknowledge that CVS has severe deficiencies, but in the near future we'll probably stay with it. Perhaps after SVN 1.0 comes out... :)
then we may want to mirror your cvs repo to subversion :-) The reason is that we want to provide consistent versions of all the libraries/modules/projects we use. And subversion makes this rather easy (if the other project is svn-controled, too), e.g. you can say 'i want to follow the HEAD version of LLVM in this branch' or 'i want to use this stable version of LLVM for my own stable-release'. Then you can just issue 'svn up' and you will have the desired versions on your working-copy. However, i can understand that you don't want to consider subversion right now and will stop advertising now :-) cheers, holger
Cool. We are all big fans of Python here. :)
That's good because we might want to recode some LLVM functionalities in Python :-)
As long as it makes sense. Needless duplication of effort is never a good idea...
I've read up a bit on PyPy, and it looks like LLVM could be a nice way to get the JIT type interface that you would like. Also, making use of the LLVM optimizer can make your staticly generated code nice and fast. :)
Yes, but we also would want to dynamically emit and execute LLVM code. But a static translation is indeed our first goal :-)
Of course. We can do both. In fact, we can even emit C code, which will be useful initially if you're work on PowerPC machines.
Thinking some more about it, we would probably try to translate our PyPy implementation into LLVM-code and also generate some glue-LLVM-code which allows us to programmatically drive LLVM from Python. Is LLVM able to "drive" itself? I mean can the LLVM-low-level object code generate LLVM-low-level object code and then execute it?
Yes, this should certainly be possible. Kindof like what the Jalapeno/Jikes JVM does with Java. The point about the C bindings is that they will allow a nice interface between the parts written in python, and the parts written in C++. It doesn't make sense for you to rewrite all of LLVM in python, especially since the interface to build the LLVM is pretty clean.
This would fit nicely with PyPy because we are running ourselves (in 'abstract interpretation' mode) in order to generate a low-level representation of ourselves. This low-level representation is already close to LLVM's low-level view. So if the LLVM-code gets executed (beeing a python interpreter) it should be able to just-in-time-compile new LLVM code and execute it. With our architecture, for such a JIT we
Makes a lot of sense.
At this point, we're working like crazy to get important features implemented in LLVM. We certainly acknowledge that CVS has severe deficiencies, but in the near future we'll probably stay with it. Perhaps after SVN 1.0 comes out... :)
then we may want to mirror your cvs repo to subversion :-)
That is obviously no problem. :)
The reason is that we want to provide consistent versions of all the libraries/modules/projects we use. And subversion makes
Makes sense. If it is publically accessible and stable, perhaps we can add information about it on the LLVM pages for others who would prefer to work with SVN... -Chris -- http://llvm.cs.uiuc.edu/ http://www.nondot.org/~sabre/Projects/
participants (2)
-
Chris Lattner -
holger krekel