[pypy-dev] Fwd: Work plan for PyPy

Richard Emslie rxe at ukshells.co.uk
Wed Jun 27 22:55:13 CEST 2007


waaaah - forget to cc everyone :-(

Begin forwarded message:

> From: Richard Emslie <rxe at ukshells.co.uk>
> Date: June 27, 2007 10:56:39 AM PDT
> To: Armin Rigo <arigo at tunes.org>
> Subject: Re: [pypy-dev] Work plan for PyPy
>
> Hi Armin!
>
> On Jun 27, 2007, at 4:40 AM, Armin Rigo wrote:
>
>> Hi Richard,
>>
>> On Mon, Jun 25, 2007 at 01:01:35PM -0700, Richard Emslie wrote:
>>>> Just a sidenote - rffi supports (and uses) macros. Not sure how  
>>>> this
>>>> will look like in a ctypes-based solution.
>>>
>>> if you are talking c macros - this could be very problematic for the
>>> llvm backend.
>>
>> Anton (which I add to the CC's of this mail) proposed a solution for
>> calling C APIs from llvm bytecode in a portable way, which would work
>> for functions whose argument types are not exactly specified by the
>> standards as well as for some kind of macros.  The idea is to  
>> generate
>> stub "helper" functions in C and compile them with llvm-gcc.  The  
>> llvm
>> bytecode that genllvm produces would then call the helper functions
>> instead of calling directly the external C API.  Shouldn't be a
>> performance problem as llvm will inline the helpers agressively.
>>
>
> ok, that is somewhat what we have now - except the stub functions  
> are high level and shared *somewhat* with genc.
>
> Generating c code in llvm backend would sort of defeat the point of  
> it IMHO.  We already have a backend that generates c.  On the other  
> hand, if we hand write the c code - it may be an neverending task  
> of adding hacks to the backend.  For instance just getting at errno  
> is particularly problematic right now - and would involve a  
> function call from a constant value.  which means injecting a few  
> lines assembly and a temporary variable.  Easy to do, but it is  
> nice right now that we pretty much have a direct mapping from our  
> our lli form to llvm assembly.
>
>
>> Of course, it points again to the question of whether it's really
>> worthwhile to have an llvm backend in PyPy or if just producing C and
>> using llvm-gcc on everything wouldn't work just as well.  On the  
>> other
>> hand, it's interesting to note that there are other reasons for which
>> exactly the same kind of helper functions would be useful; for  
>> example,
>> to wrap a C library full of macros and unspecified types and  
>> constants,
>> ctypes alone is not enough.
>
>
> Like you say, llvm-gcc (well at least v4) would probably produce  
> equivalent results with genc.  The way we are using llvm right now  
> (as a static compiler) i'm not sure of its worthiness either of  
> keeping the backend alive.  Other than the potential of accurate  
> gc, potential of jit (which is sort of orthogonal to this),  
> potential of producing vectorized code from rpython...
>
>
> Cheers,
> Richard
>
>
>
>
>
>




More information about the Pypy-dev mailing list