[pypy-dev] sprints goals / restricted python?

[holger krekel]

[Armin Rigo Wed, Jun 18, 2003 at 04:11:27PM +0200]
> Hello Holger,
> 
> On Tue, Jun 17, 2003 at 02:39:36PM +0200, holger krekel wrote:
> > I don't know but i think going the TranslationObjSpace way
> > might turn into complicated code.
> 
> Actually, you describe a nice AnnotationObjSpace that is almost exactly what I
> had in mind. In other words I don't think there is much more to the
> AnnotationObjSpace until we can make it produce usable C code. (Btw I'm not
> sure emitting Pyrex-annotated code would be any different nor particularly
> easier.)

It seems to me that 

a) Pyrex would allow for a smoother transition to RPython because
   we could run parts of our interpreter as C-modules. If we have
   the whole running we can migrate to our own RPython-C-base library. 

b) Pyrex' extended python syntax seems to be easier to generate,
   especially starting from annoated python-source 

Btw, i have no assets with Pyrex and only glanced at documentation+src
without using it much. 
 
> This is the crucial example:
> 
> > For example how do you
> > "detect" a loop from an objectspace's POV? It just sees 
> > a series of a series of ObjSpace-Method accesses and it seems hard 
> > to reverse engineer the loop.
> 
> Here is the idea. You are right in that the object space cannot see that loop
> at all; but we don't necessarily want to produce a nice C-style 'for' loop for
> it -- who said we wanted to produce *nice* C code ;-)

... space-time tradeoff, i knew it :-) ...

> Instead, the translator keeps variable type annotations like you described for 
> AnnotationObjSpace, but it keeps one such structure for *each* bytecode 
> position. Hoping that this doesn't competely blow away the memory when the 
> translator is run, we can detect when the annotation work is done by the fact 
> that we have got back to an already-seen position and our current annotations 
> for it at not more general than what we have already recorded.
> 
> Translating the result to C is then quite straightforward. The object space's
> methods like space.add(), when called, would attach one or a few lines of C
> code to the current bytecode position. When the annotation pass completes, we
> just emit a C function whose body groups all these lines in the bytecode
> order.

ok, now i understand it more. I am not sure if starting from the interpreter 
source would be as/less/more efficient, though :-) Any guesses? 
 
> For jumps (like loops), we add in the body a label for each bytecode position
> (e.g. 'b123:' for the bytecode position 123) and then the C equivalent of
> 'JUMP_IF_TRUE 123' is 'if (...) goto b123;'. It doesn't make nice C loops --
> looks more like assembly code. Similarily I don't imagine that Python "if"  
> constructs will give nice "if(...) {...} else {...}" in C, but again some
> horrible block-less stuff with gotos.

sounds like psyco :-)
 
> Actually getting nice C code would be another matter, but I don't really mind
> right now.

who would. It's nice that we agree about the AnnotationObjSpace so this
is a starting point.  Are you in Louvain-La-Neuve on Friday evening 
or are you staying in Bruxelles? 

cheers,

    holger