[pypy-dev] Next step: gen???.py
hpk at trillke.net
Thu Mar 31 14:00:28 CEST 2005
On Thu, Mar 31, 2005 at 09:29 +0100, Armin Rigo wrote:
> On Wed, Mar 30, 2005 at 07:48:43PM +0200, holger krekel wrote:
> > (... C++ ...)
> > Wouldn't this mean that we are barred from using "tcc" for
> > testing/debugging purposes?
> That's an excellent point.
> I played with a more promizing approach in
> http://codespeak.net/svn/pypy/dist/pypy/translator/typer.py . Basically,
> instead of enhancing genc to support all kind of typed operations and implicit
> conversions (or rely on C++ to select the operations and insert these
> conversions automatically), the abvoe module contains code that modifies the
> flow graph itself to turn it into a "low-level" flow graph. The idea was
> already floating around here.
Actually i woke up this morning with exactly this idea in mind :-)
In other words, i agree that this is probably the cleanest/nicest way
to go and share code between the backends.
> In short it turns code like
> z = add(x, y)
> z = intadd(x, y)
> if x and y are SomeIntegers, and it inserts int2obj() and obj2int() operations
> to convert variables that are SomeIntegers but used in operations that can't
> be special-cased (most of them, right now).
I was wondering if it makes sense for such conversions to be determined
at the flowgraph-level and conversion operations to be inserted accordingly?
This could be a transformation that is specific to genc, genc++ and genjava
with Jython (or even genllvm + cpython-bindings) ... in short almost for
all the current or envisioned backends :-)
> The idea is then that genc only needs minor updates to give
> various C types to the variables. The operations like
> intadd() can be defined as a macro in genc.h, just like all
> the other operations.
Yes, in addition with the conversions at the flowgraph level the
genc backend should become pretty simple.
> The module is called "typer" because I guess that a clean solution would
> involve a dict that maps Variables and individual Constants to their C type,
> instead of relying implicitely on the SomeXxx annotations to mean particular C
More information about the Pypy-dev