[pypy-dev] Ideas on pypy architecture (ala tismer)

sismex01 at hebmex.com sismex01 at hebmex.com
Tue Feb 18 20:49:06 CET 2003


> From: Arman Bostani [mailto:arman at twinsun.com]
> Sent: Tuesday, February 18, 2003 1:11 PM
> 
> A long time ago I worked on a Prolog compiler which had the following
> design.
> 
> * The system had an abstract machine specification which is analogous
>    to the Python byte code instructions.
> 
> * There was a second, very low-level instruction set (called progol)
>    which was essentially a set of macros from which assembly code was
>    generated.  To port to a new architecture, new mappings for progol
>    instructions were defined.
> 
> * The system was able to compile the abstract machine instructions
>    directly to progol.  Also, a Prolog interpreter was written in
>    progol.
> 
> Now I think Pypy might benefit from a similar architecture.  My
> suggestion is as follows:
> 
> * Examine the entire C code base and come up with a low-level
>    instruction set (let's call it pynoth).  As above, this instruction
>    set would be just a bunch of macros but probably translated to C
>    rather than assembly.
> 
> * Write a semi-automated converter (ala tismer) to translate the
>    existing C code into pynoth.  Perhaps, if the pynoth code 
> can retain
>    comments and look semi-decent, the Python gods will accept 
> to use it
>    rather than the existing C code base.  If not, then we'd have to
>    retranslate new/modified sources to pynoth as python changes.
> 
> * Develop a psyco-style code generator which generates pynoth instead
>    of assembly.
> 
> * Over time, we can get rid of the hand-hacked pynoth code and rewrite
>    much of the system in python.
> 
> -arman
> 
> -- 
> Arman Bostani                            360 N. Sepulveda Blvd. #2055
> Twin Sun Inc.                                    El Segundo, CA 90245
> arman at twinsun.com            Tel: (310) 524-1800, Fax: (310) 524-1818
>

Hello all, I've been lurking around this list for a while,
I hope I don't make a complete fool of myself :-)

I have only a single question: Why compile to C, when that
language has a number of shortcomings which could be eliminated
by picking a different target?

By "shortcomings", I'm referring to certain aspects of
generated code which become inaccesible, simply because C
does not facilitate access to those aspects.

One of the main aspects I'm talking about is the machine
stack.  How do you "continue" to another function?  How do
you inspect the return stack to gain knowledge from the
calling sequence to arrive to a certain execution point?

I've been playing a bit (emphasis on "playing", nothing
serious yet) with forth, and the language itself provides
easy access to the machine stack, without having to resort
to strange contortions or inline assembly.  Continuations
and co-routines are written in some 20 lines (simple
implementations), without requiring access to mind-bending
hacks.

Of course, many might say that Forth is *like* inline
assembly in some aspects, but the kernel may well be hidden
from sight and yet you still retain access to those aspects,
normally hidden in C.

I'm not advocating Forth as an intermediate language,
it's plenty wierd, mostly I'm questioning C's use.

Any comments on the following are plenty appreciated.

Thanks.

-gustavo


More information about the Pypy-dev mailing list