[pypy-dev] Work plan for PyPy

Richard Emslie rxe at ukshells.co.uk
Fri Jun 29 01:40:37 CEST 2007


Hi Armin,

On Jun 28, 2007, at 4:15 AM, Armin Rigo wrote:

> Hi Richard,
>
> On Wed, Jun 27, 2007 at 01:55:13PM -0700, Richard Emslie wrote:
>>>> 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.
>
> Precisely, by contrast I'm thinking about having lower level stub
> functions that are generated automatically from the lltype  
> declarations.
> For example, an external ll function ptr would generate a simple stub,
> always the same.  GenC and GenLLVM would share the code to produce the
> stubs.  Similarly, getting at an external variable (or variable-like
> macro) like errno should be expressable in an lltype way (it's not  
> right
> now) that gets turned into """int _rpyget_errno(void) { return  
> errno; }""".
>

Ok - cool.  I was hoping to propose something along these lines - but  
was unsure how to go about it.
This would be ideal and work great for backends.  I am guessing all  
memory management with this would
be explicitly controlled from outside the stubs?


>>> Generating c code in llvm backend would sort of defeat the point of
>>> it IMHO.
>
> The difference is that the stubs would always be generated from simple
> templates, not from genc's complex logic that turns flow graphs into C
> code.
>

Yeah - this sounds fantastic.  No clue how to do it - but great! :-)

Well - I'm in the process of migrating back home... again.  Once i  
get back though I can devote lots of time to this.
I doubt i can make the sprint, but will try.

Cheers,
Richard





More information about the Pypy-dev mailing list