[Python-de] Minimal Python, Nachsatz

[holger krekel]

Christian Tismer wrote:
> Christian Tismer wrote:
> 
> Holger Krekel schrieb:
> ...
> 
> >> Vielleicht liesse sich der schon in Python schreiben? Erst mal klingt 
> >> das widerspruechlich. Wie sollte der Interpreter
> >> jemals einen bytecode interpretieren, wenn diese interpretation
> >> auch wieder aus der interpretation von bytecodes besteht.  
> ...
> 
> >> Andererseits ist es durchaus vorstellbar, einen Interpreter komplett 
> >> in python zu schreiben.  Es hindert uns nichts daran, die C-Frame 
> >> Funktionalitaet in python zu implementieren, oder?  Insofern duerfte 
> >> das "nur" ein bootstrapping problem sein.  
> 
> Habe nochmal kurz nachgedacht -- eigentlich hast Du
> ja recht. Natürlich kann man einen kompletten
> Interpreter in Python schreiben und sich zunächst
> um nichts weiter kümmern. Das würde dann als
> Aufsatz von Standard-Python laufen.

und waere - obwohl sehr langsam - ein gutes Testbett
fuer den bytecode-level.  analog zu 

compile.c <-> pycodegen.py dann 
ceval.c <-> pyeval.py 

> Allerdings müßte man dann stückweise einen Übergang
> des in Python laufenden Interpreters zu etwas Neuem,
> Eigenständigen basteln. Es ist die Frage, ob das
> nicht ein Umweg ist?

gute frage.

ein pyeval.py waere sicher instruktiv. Und es waere ein 
gut releasebarer Meilenstein :-)

Ich vermute zum beispiel, dass viele bytecodes rekursiv 
sind, d.h. dass der bytecode einer bytecode-interpretation 
sich letztlich selbst enthaelt.  Das gilt nicht nur fuer 
sowas wie CALL_FUNCTION (dessen python interpretation mit 
sicherheit einen CALL_FUNCTION bytecode beinhaltet), sondern 
wahrscheinlich schon fuer LOAD_FAST.  eine naive 
python-implementierung saehe vielleicht so aus:

   ...
   elif op==LOAD_FAST:
        stack.append(fastnames[oparg])
   ...

aber der bytecode fuer die codezeile "stack.append..."
wuerde selbst 'LOAD_FAST' benoetigen.  Wenn wir 
'self-contained' werden wollen, muesste der obige 
sourcecode auf etwas abgebildet werden was sich letztlich
nicht selbst aufruft. Das duerfte ja in deine Stackless
Philosophie passen :-)

> Vielleicht macht es Sinn, wenn dieser Interpreter
> wirklich *alles* implementiert.

macht schon Sinn, ist nur etwas unabsehbar. IOW
eignet sich nicht als Meilenstein :-)

> Es müßten auch
> die erforderlichen Datenstrukturen emuliert werden,
> in einer Weise, die die Transition zu einer
> "realen" Implementierung überlebt. Insbesondere
> hieße das, eine Python-Beschreibung für C-Strukturen
> zu entwickeln.
> Macht es Sinn, dafür das Struct-Modul
> einzusetzen, oder macht man es "abstrakt" uber
> entsprechende Klassen?

da kenne ich mich zuwenig aus, aber wenn man mit
struct oder ctypes (!?) beliebige C-Strukturen
lesen und schreiben kann, sollte das helfen. 

> Stattdessen könnte man gleichzeitig "von unten"
> anfangen und erforderliche minimale Basisstrukturen
> in C entwickeln.
> 
> Wenn man z.B. eine Frame-Struktur passend in C
> anlegt und alle Felder für Python zugreifbar macht,
> könnte man das "von unten" an die Interpreter-Schicht
> weitergeben, welche dann, in Python, darauf operiert.

Mir erscheint vielversprechend, pyeval.py zu schreiben 
und dass dann auf einem minimalisierten ceval.c zum 
laufen zu bringen.  Das neue ceval.c brauechte keine 
nested scopes, keine iterator-bytecodes, keine 
namespace-optimierungen etc., weil sich diese features 
in pyeval.py mithilfe der restlichen bytecodes 
simulieren lassen koennen muessten. 

Mir gefaellt an diesem Vorgehen, dass man von python-code 
losgeht und der C-Code schrittweise vereinfacht bzw. 
pythonifiziert wird.  Ohne Armin's Magie waeren wir 
allerdings geschwindigkeits-technisch verloren. 

gruss,

    holger