RE: [pypy-dev] Ideas on pypy architecture (ala tismer)
From: Arman Bostani [mailto:arman@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@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
participants (1)
-
sismex01@hebmex.com