[pypy-dev] Next step: gen???.py

holger krekel hpk at trillke.net
Thu Mar 31 14:00:28 CEST 2005


Hi Armin, 

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)
> 
> into
> 
>   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
> types.

good point. 

cheers, 
    
    holger



More information about the Pypy-dev mailing list