[pypy-dev] C interpreter written in Python, and running CPython on top of PyPy

[Celil]

So if I understand correctly, the flow graph is simply there to help 
deduce low level types for the high level python objects so that rpython 
can be translated into C, and they play no role in the interpreter?

For some reason I was under the impression that the interpreter, as it 
loads a python module, uses the flow graph to deduce which parts of the 
code are a proper subset of rpython, and compiles them to produce more 
efficient modules.

Celil

On 1/6/12 7:52 AM, Armin Rigo wrote:
> Hi Celil,
>
> On Fri, Jan 6, 2012 at 15:59, Celil<celil.kj at gmail.com>  wrote:
>> Is anybody already working on that? With PyPy this would presumably be quite
>> easy to do. The interpreter will load the C code, create an AST (presumably
>> using pyparsing and the EBNF spec of the C-language), and then populate the
>> Flow Object Space with all the C objects, and create a control flow graph of
>> the application logic.
> I think you are confusing several levels.  I don't see what you would
> gain by this exercise.  Interoperability problems between C and PyPy
> are not going to be magically solved just because we turn C code into
> lltyped flow graphs.  That seems rather pointless: from lltyped flow
> graphs, what we do is mostly turn them into C code again.
>
> For an example of the confusion:
>
>> Interpreting C code would greatly help
>> CPython developers by freeing them from the task of having to repeatedly
>> compile their code.
> No: flow graphs need to be created (a Python process that is slower
> than gcc), then turned into more C code (more time), and finally
> compiled... by gcc itself.
>
> Unless you really have in mind an interpreter-with-JIT for the C
> language, fully written in PyPy; but in this case there are no flow
> graphs around.  Our JIT would give bad results anyway, because C is a
> low-level language, not a dynamic language.
>
>
> A bientôt,
>
> Armin.