[pypy-dev] Re: Project suggestions

Armin Rigo arigo at tunes.org
Sat Oct 1 19:59:25 CEST 2005


Hi Aurelien,

On Sat, Oct 01, 2005 at 02:44:50PM +0200, Aur?lien Camp?as wrote:
> I would tend to provide a huge prelude implemeting a close aprox. of 
> those in CL (it is my plan).

Yes, this would be possible.  I suppose even dark corners like
dictionary with user-specified ways of computing the hash of keys could
be done this way.

> >and then there are
> >rather more obscure annotations like SomePBC() that are quite involved.
> >Just to frighten you a bit, you'd also need at some point to do
> >something like pypy/rpython/normalizecalls.py :-)
> 
> I can't really be frightened by something I don't know about nor 
> understand ...

That's the problem, I suppose.  RPython is larger and more delicate than
it seems to be at first.  After a lot of trashed efforts in GenC, we
eventually found out the correct approach, which is:

> >What we have in mind is to support targets like CL by a modified RTyper
> >(pypy/rpython/r*.py); it means that there would be an additional
> >processing step between the graph-with-annotations and the CL backend
> >which would simplify the graphs and replace complex operations and
> >annotations with more primitive ones.  This will make the task of the
> >backend far easier.

Compare the flow graphs after annotation and after rtyping (e.g. with
translate_pypy.py targetrichards.py --annotate  versus --rtype).  The
latter are in a very controlled format, using strict C-like types
(structures and arrays and nothing more).  Even the constants are
prebuilt structures and arrays.  It is the rtyper that does the hard job
of converting from the annotated graphs to these low-level graphs.

For backends that are a bit higher-level than C, we need some
intermediate solution that uses some parts of the rtyper and some parts
of the direct code generation you have in mind.  That's also something
we should discuss at the Paris sprint with Bert, as it is what a
Smalltalk back-end should need as well.

But for now I suppose that writing the direct code generation for the
easy parts is the best way to start.


A bientot,

Armin.



More information about the Pypy-dev mailing list