-----Original Message----- From: pypy-dev-bounces@codespeak.net [mailto:pypy-dev- bounces@codespeak.net] On Behalf Of Rocco Moretti Sent: Monday, January 20, 2003 11:08 PM To: pypy-dev@codespeak.net Subject: Re: [pypy-dev] question about core implementation language
logistix <logistix@zworg.com> wrote:
I think the point is that Python as a language provides absolutely no access to the machine internals. You can't examine memory contents, registers, I/O bus or call code directly.
Can you do this all in C? (without library functions coded in assembly)
As part of the bootstrap process the following four functions should probably be added to the interperter (either as builtin functions or a module):
GetMemoryFromOS() ReturnMemouryToOS() Peek() Poke()
ANd probably: get/putRegister() callCode()
Other than that, everything could (eventually) be written in Python.
If we were writing an Operating System, I would agree with you. (We can put down a Python based OS as another goal of the project. <while 1:wink()>)
Fortunately, we aren't quite so low level. The standard OS functions tend to be higher level. As I understand it, much of libc.so on Unix systems is simply a very thin wrapper around OS functions which behave much like the C functions that call them.
Since we don't want to reinvent the wheel, it would probably be best to reuse the standard interface provided. This is where the minimal C core comes in. We can probably limit it to basic input and output (PyBIOS?), plus a generic mechanism for discovering and calling dll/so functions.
Or am I missing your point entirely?
-Rocco
Yeah, Armin also seemed to disagree with me. Here's where I'm coming from (and maybe I'm missing a very big part of what psycho does). Okay we've got a theoretical python interpreter written in python. It: Compiles to python bytecode Uses this to generate C code(or other backend) Uses VC++ or gcc to generate machine code This all works well and good until the interpreter calls eval() or exec (like it does via the code module anytime you do something in IDLE or PythonWin, or even importing an updated module) what happens in this case? The way I see things now, you'd have to: Compile to bytecode Generate C (or other backend) Create dll/so Load DLL/SO into python I would want some way to load code directly into memory (and preferably with minimal File I/O). Hence a few low level memory functions (coded in C or assembly) that are callable from the Python framework. Everything else would be written on a higher level. Is the above the intended workflow for interactive compilation or am I just being an idiot here? ;)
Hello Logistix, On Tue, Jan 21, 2003 at 05:38:58PM -0500, logistix wrote:
I would want some way to load code directly into memory (and preferably with minimal File I/O). Hence a few low level memory functions (coded in C or assembly) that are callable from the Python framework.
Now I think I see what you meant. But there are two different C-emission processes that we are talking about: 1) given the Python interpreter written in Python, we want to statically translate it into some CPython-like C code, experimenting variants etc. but always having a "classical" (non-Psyco) interpreter. This should be regarded as the goal of the project right now, focusing on nice Python code, not specifically optimized. Most of the C code making this new interpreter should come from 100% automatic translation of the Python-in-Python; it could be completed with a few C modules that handle all issues specific to C (e.g. dynamic loading libraries or signal polling). 2) later, we can add a Psyco layer made of some (hopefully small) parts of the current Psyco, and some specific back-end code (which may or may not be written directly in C). As above the most important part of this project must be 100% automatically translated from the Python-in-Python. I think the issues you mention arise if we want to write absolutely everything in Python, which I think we don't: issues specific to the final C/ObjC/OCaml/wantever translation may be coded in C/ObjC/OCaml/whatever, as far as I'm concerned, and the same with Psyco. A bientôt, Armin.
participants (2)
-
Armin Rigo -
logistix