[pypy-dev] Hi!

[Carl Friedrich Bolz]

Hi Holger!

On Thu Feb 3 09:46:08 MET 2005, Holger Krekel wrote:
> One of the obstacles regarding LLVM is indeed its installation
> process, as is often the case with large C++ codebases not
> packaged by the distributions.  If we want to use LLVM more
> then we should try to provide supplemental installation
> instructions i guess.

I can provide provide you with some pointers (Maybe I should write
these installation instructions at one point): One of the biggest
problems for me was that LLVM needs a farely recent GCC-Version to
even compile. I think they recommend GCC 3.3.3/3.4.0 or later --
earlyer versions give "Internal compiler errors" or somethin like
that. If you have a recent version of GCC installing the main LLVM
package is still relatively easy.

What's more difficult is the
cfrontend package which is needed if you want to be able to compile
c/c++ code to LLVM. This package consists of the ripped-of
GCC-frontends for these languages. A precompiled version of this
package exists for some platform. If these don't work (which they did
for me eventually) you have to compile cfrontend:

Quote from the docs:
"""This is currently a somewhat fragile, error-prone process, and you
should _only_ try to do it if:
1. you really, really, really can't use the binaries we distribute
2. you are an elite GCC hacker
"""

One the other hand is the cfrontend not needed to user LLVM. You need
it only if you want to compile c-code with it which is not neccessary
for my llvm-backend for pypy (but might become so in the future).


>> In my opinion this can be extended to nearly all of Python's data types
>> as long as the annotation succeeds. I cannot yet judge wether other
things
>> like classes, exception handling, garbage collection etc. will be easy
but
>> we shall see.

> Oh don't worry, the other backends don't care too much for
> this, either :-) The Pyrex and GenC still cooperate with the
> CPython runtime and borrow its garbage collection among other
> things.  Once we target a standalone (without the CPython
> runtime) version garbage collection needs to be done. (Usually
> at this point sometime drops in the two words "Boehm collector" :-) 
> Exceptions get analyzed by the flow space in a way that makes
> generation of low-level code rather straightforward.

I don't know enough about the memory management of LLVM to decide
whether we can use the "Boehm collector". As far as I see it, it is a
c/c++-library which could be difficult to use from within LLVM. LLVM
has some gc-hooks though (and I think even a very simple gc to show
how to use these), maybe we can work with that.

> I think it makes sense. It would be great to have you at one of our
> next sprints and further explore the LLVM backend, i think.  Btw, 
> Armin and Christian intend to do cleanup work on the translator 
> backends and it is sensible to already have LLVM in mind.

I won't be able to go to PyCon but I hope I can make it to one of the
sprints after that at PyCon. Is there some sprint planning that goes a
bit beyond just the next one? I'm even thinking about organizing a
sprint here in Heidelberg this summer/fall though I don't know whether
this will fly.

> What i would like to find out is if we could use a stripped
> down version of LLVM because i also guess that many
> supplemental (code generation) tasks are better done in Python
> than with wrapping and using some of the LLVM API. I guess i am
> going to download and try-installing the thing again :-)

We can probably try not to use the API altogether. Then we would only
need the command line tools. The APIs would be useful for something
Psyco-like though as it is possible to emit code and do
JIT-compilation , and use it on-the-fly without writing anything to a
file first.

Regards, 
    
    Carl Friedrich