[Python-Dev] Parrot -- should life imitate satire?

[Steven D. Majewski]

Since python does so much by name (I think locals are the only
place where name lookup is compiled away), dictionary lookup
is pretty fundamental to the runtime, and is used by a number
of opcodes. No reason that dictionary lookup couldn't be part
of the common runtime, or else tucked behind an abstract 
interface common to Python and Perl lookups, but it's something
to keep in mind if the VM is going to operate on a similar 
level to the current one. 

But then, I've always thought that one of the problems with
trying to optimize Python was that the VM was too high level. 

If some sort of Forth-like extensible threaded code were used,
you could build the current opcodes from lower level primitives.

Re: stack vs. register machines:

Some Forth implementations cache some of the top of stack in
registers, but the more you try to cache, the hairier it gets.
( But you can figure out the bookkeeping once and automatically
  generate the code variations. ) 


You might take a look at Anton Ertl's VMGEN:

	<http://www.complang.tuwien.ac.at/anton/vmgen/>

| Vmgen generates much of the code for efficient virtual machine (VM)
| interpreters from simple descriptions of the VM instructions. 


[  One of the nice/useful features of the the Forth VM is the PFA/CFA
  pairing: PFA is "parameter field address" and points to the code 
  ( VM or native ) to be executed. CFA is "code field address" and
  points to the code to interpret what's in the parameter field. 
  For threaded code, it points to the threaded code interpreter; 
  for native code, it points to the PFA -- i.e. native code is
  'self interpreting' . BUILDS/DOES in Forth creates a data type
  (BUILDS) and defines code to addess the data type (DOES) that is
  pointed to by the CFA -- an early but very primitive object-orientation, 
  but with only one method (later Forth's added QUADS and other methods
  to have separate ACCESS/UPDATE (read/write) methods. ]


Re: Other VM implementations:

I'm not very familiar with the internals of Squeak, but I suspect 
that it's worth looking at. They are, in any case, interested in
some of the same sort of things. ( There was a recent thread about
MIT's StarLogo -- which was originally written for the Mac using
(I think) Lisp, and then a portable version was done using Java, 
but they were disappointed in performance, and I think they are 
looking at using Squeak now. ) 


Scheme48 is probably considered the best portable byte-code Scheme
implementation. ( Don't know anything about it's internals myself )


 A lot of other people who have tried using the Java VM for other
languages have had complaints about various things that are difficult
or impossible. ( Scheme folks couldn't have full call/cc, and there
were two different attempts to add generics to Java -- one involved
adding special bytecode support, and the other (Pizza -- now GJ --
Generic Java) tried to stick with a standard Java VM. ) 
 
-- Steve majewski