Objective of minimal python
I've lurked on the periphery of the discussions so far and must admit to being somewhat lost as to what exactly is being proposed. Am I correct in believing the following? 1. That the objective of the project is to create a new implementation python that: i. Has a smaller memory footprint; and ii. runs applications faster than the current interpreter; and iii. is well suited to applications making significant use of lightweight threads and continuations. 2. To achieve this it is intended to rewrite the 'front-end' of the Python interpreter, specifically the language parser, lexical analyser and compiler / byte-code generator, in python itself. 3. The byte-code interpreter (is this the same as the virtual machine?) is a program that reads the byte-code stream as data and processes it to do 'real work'. In order to meet objective (iii), it is intended to write a new VM that employs structure and mechanisms seen in the 'stackless' implementation. There are three possible implementations of the VM: i. It could be written in 'C' and call the 'C' runtime library execute functions implied by the byte-codes, e.g. allocation of space, arithmetic functions etc. Such an approach could draw heavily upon the code base of the 'execution engine' (I don't know what it's really called) of the existing VM. ii. It could be written in any language (including, but not limited to, 'C') and convert the byte-code stream into 'C' (or, indeed, any other statically compiled language), to be passed off to a compiler for compilation, linking and subsequent execution. This advantage of this approach is that it can exploit the considerable advances that compiler writers have made in code optimisation. I presume that the reason that the byte code, rather than python source code, is converted to 'C' is to be able to reuse existing compiled classes for which one does not have access to the source. iii. I could emit machine specific assembly language instead of 'C'. If understand correctly, this is what Psyco does. The advantage to this approach is that the code emited can be modified as the execution of the program (byte-code stream) evolves, thus permitting optimisations to be performed that cannot be achieved in a statically compiled language. This disadvantage is that it would be a very considerable effort generally to produce assembly language that is as highly optimised as a good optimising compiler might achieve. I'd be most grateful for your comments. Regards, David Roper mailto:droper@lineone.net
1. That the objective of the project is to create a new implementation python that: i. Has a smaller memory footprint; and ii. runs applications faster than the current interpreter; and iii. is well suited to applications making significant use of lightweight threads and continuations. 2. To achieve this it is intended to rewrite the 'front-end' of the Python interpreter, specifically the language parser, lexical analyser and compiler / byte-code generator, in python itself. 3. The byte-code interpreter (is this the same as the virtual machine?) is a program that reads the byte-code stream as data and processes it to do 'real work'. In order to meet objective (iii), it is intended to write a new VM that employs structure and mechanisms seen in the 'stackless' implementation. From what I have read so far, this summary is incorrect. (Any corrections to what I am saying are appreciated, tho!) Here is what I understand: 1. The objective of the project is to create a new implementation of python that: i. Has as small and simple a C core as possible ii. Uses python itself to provide as much of the functionality of the "standard" CPython implementation as possible. 2. This new python implementation will not necessarily be stackless, nor be particularly fast. The idea is -- at least at first -- to produce a complete python implementation *in python* that then can be optimized using various dynamic techniques (such as those in psyco) or easily extended with new language ideas (like stackless). 3. A possible side-effect of implementing python in python is that python may become impressively modular -- leading to its use in small and embedded platforms. However, this is a possible side-benefit, and is not the primary focus of this effort. 4. Pysco and pyrex are possible starting places for the small C core. In fact, this is much more of a microkernal-python than a minimal python. VanL
4. Pysco and pyrex are possible starting places for the small C core. -- Nathan Heagy
This might be as good a point as any to jump in with my question: is there planned support for non-x86 platforms? I'm an OS X geek and was disappointed that psycho is only for x86. On Thursday, January 16, 2003, at 02:38 PM, VanL wrote: phone:306.653.4747 fax:306.653.4774 http://www.zu.com
Hello Nathan, On Mon, Jan 20, 2003 at 12:51:00PM -0600, Nathan Heagy wrote:
This might be as good a point as any to jump in with my question: is there planned support for non-x86 platforms?
Yes, I expect the new Psyco-like code to be much more flexible and easy to port to other processors. We are also talking about mixed approaches involving gcc. A bientôt, Armin.
participants (4)
-
Armin Rigo -
David Roper -
Nathan Heagy -
VanL