[pypy-dev] (no subject)

[logistix]

> -----Original Message-----
> From: pypy-dev-bounces at codespeak.net [mailto:pypy-dev-
> bounces at codespeak.net] On Behalf Of Rocco Moretti
> Sent: Monday, January 20, 2003 11:08 PM
> To: pypy-dev at codespeak.net
> Subject: Re: [pypy-dev] question about core implementation language
> 
> logistix <logistix at 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? ;)