...

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/

...

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/