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<[email protected]> 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.
_______________________________________________
pypy-dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/pypy-dev
