[pypy-dev] sprints goals / restricted python?

Armin Rigo arigo at tunes.org
Wed Jun 18 16:11:27 CEST 2003


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

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 ;-)

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.

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.

Actually getting nice C code would be another matter, but I don't really mind
right now.


A bientôt,

Armin.


More information about the Pypy-dev mailing list