[pypy-dev] Minimal VM

[holger krekel]

[Paul Boddie Tue, Jan 14, 2003 at 08:41:28AM -0800]
> Christian Tismer <tismer at tismer.com> wrote:
> >
> >There will be a very tiny, portable little virtual
> >machine written in C. It is not meant to be efficient,
> >just enough to implement the bytecode interpreter.
> >I'm right now tinkering with parts of such a beast.
> >It is getting very small, just a few kilobytes executable.
> 
> The most interesting parts, it seems to me, will be those 
> which implement the more complicated bytecode semantics (like LOAD_NAME, 
> for example, which seems to have the potential to be pretty deep).

that's actually pretty easy. it's basically (from eval_frame in compile.c):

    case LOAD_NAME:
            w = GETNAMEV(oparg); 
            if ((x = f->f_locals) == NULL) { // exception ... }
            x = PyDict_GetItem(x, w);
            if (x == NULL) {
                x = PyDict_GetItem(f->f_globals, w);
                if (x == NULL) {
                    x = PyDict_GetItem(f->f_builtins, w);
                    if (x == NULL) { // exception ...  }
                }
            }
            Py_INCREF(x);
            PUSH(x);
            break;

so it looks into local, then global and then the builtin namespace. 

> Although you are bound to know much more about this than me - 
> I've never looked at the Python VM source code - 

btw, it's quite easy to read if you know C.  It's pythonic C mostly :-)

> there must surely be a huge chunk of C code implementing the 
> name lookup semantics.

not that much if you don't count the Dict object in.
some complexity drops in with optimizations and special cases:  

    - local name-bindings are usually mapped to LOAD_FAST/STORE_FAST 
      which don't go through a dictionary lookup but use integer indexes
      into an array.  these are figured out at compile time. 

    - nested scopes (LOAD_DEREF) which bind a name to an outer namespace

they probably aren't needed for a Stage1-VM.  Also a big part is 
exception (and block) handling. 
 
> >This thing will be able to interpret Python bytecode.
> 
> Without getting carried away by the promise of massive performance 
> increases, an interesting application of a simplified VM should be 
> the increased potential for reimplementations of the platform. It 
> would be most amusing to be able to reduce the scope of VM 
> operations such that they could be more easily implemented 
> on "really small" computing platforms.

There will be a memory-speed tradeoff, though.  So if
"small" means 1M memory the odds are that a CPython based
approach is more effective. 

> Of course, a side effect of having simpler VM operations (ie. 
> simpler bytecode semantics) is that Psyco (or its successor) 
> will have much more to play with, as more of the VM "magic" 
> moves out of the VM and into bytecode routines which can 
> then be specialised.

IMO the CPython VM is pretty straight forward.  But
the fact that Psyco hits the C-barrier too soon (with the
frame object and the eval_frame loop) stops it from
going/specializing deeper. 

cheers,

    holger