[pypy-dev] genrpy is ready so far.

[Christian Tismer]

Hi Armin, all,

I've put quite some work into genrpy.py in the last
few weeks. It seems to produce usefulcode, although
it could of course be nicer with some more effort.

The speed effect appears to be somewhere around 40%
over interpreted appspace code, not really disappointing,
but also not really overwhelming.

The real effect of such translation lies probably in
opening things to further optimization in a later
code generation step.

The code works fine with
_formatting.py, md5.py and strutil.py. These all
appear to obey RPython restrictions, as probably
many others.

There are some enhancements possible:
Right now, I'm using the flow space as it is, but I do
not try to create specialized functions for constant
arguments. Flow space provides some way to do this,
but translator doesn't allow it. I'm thinking to play
with this. It would make much sense in the md5 module,
where many small functions with constant arguments
could be curryfied.
In effect, with some more support, the flowspace could
identify more constants than it does now.

The way I'm creating the function interfaces is working,
but less than optimum. I stupidly followed the pattern
that Armin used for C code generation. Later on I figured
out that I could create functions with names and default
arguments directly. Armin, I'm referring to the distinction
of f_<funcname> and fastf_<funcname>. Instead of using the
pattern def f_<funcname>(space, *args_w)
and later plumbing the defaults in, I could have done it in
the function header, directly.
I will enhance this later, provided that we want to use this
module at all.

How do we want to integrate this stuff?
First I think it needs a different name.
Then, there is the question whether there should
be one huge module generated from the union of all
app-space implementations, or if there should be
onefile for every app-spacemodule part?
I thought of acontainerlike pypy.appspace.generated
where all stuff could be accumulated.
Do we want togenerate stuff on demand, based upon
modification time of modules, or better do it by hand?

Another questio is if it is so good to loose all the local
names early,or if I should try to regenerate local names
wherever possible?

Another thing I was considering is not to create all these
goto blocks, but to turn them into simple functions.
This would give us massive recursion, but if we add
a tail recursion feature to pypy, this would show up
quite nicely. It would make the source shorter and would
really allow to use given local names, because each
code block has its own closure, then.

I have done a lot of local tests. The test code is still
sitting in the module and should go elsewhere.
I did not yet tryto integrate it into the app space calls
of stdobjspace. This is easy to do,but I need consensus
how wewant this to happen.

Please review. You can select a few test functions by
changing line 1084. For the current main function,
you need to create an importable appspace/generated folder.
You also will needto change the temp output file for your
needs, at the moment this is "d:/tmp/look.py" :-)

I will supply a real entrypoint and a cleaner interface
when I have some feedback.

all the best -- chris
-- 
Christian Tismer             :^)   <mailto:tismer at stackless.com>
tismerysoft GmbH             :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9A     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
work +49 30 802 86 56  mobile +49 173 24 18 776  fax +49 30 80 90 57 05
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/