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

[Dan Sugalski]

At 09:03 PM 8/1/2001 +0200, Samuele Pedroni wrote:
>Hi.
>
> >
> > The point is to put the commonly called things in the vtable in a way that
> > you can avoid as much conditional code as possible, while less common
> > things get dealt with in ways you'd generally expect. (Dynamic lookups 
> with
> > caching and suchlike things)
>
>If I'm right, you're designing a object-based VM.

More or less, yep, with a semi-generic two-arg dispatch for the binary 
methods. The vtable associated with each variable has a fixed set of 
required functions--add with 2nd arg an int, add with second arg a bigint, 
add with second arg a generic variable, for example. Basically all the 
things one would commonly do on data (add, subtract, multiply, divide, 
modulus, some string ops, get integer/real/string representation, copy, 
destroy, etc) have entries, with a catchall "generic method call" to 
handle, well, generic method calls.

It's all designed with high-speed dispatch and minimal conditional branch 
requirements in mind, as well as encapsulating all the "what do I do on 
data" functions. Basically the opcodes generally handle control flow, 
register/stack ops, and VM management, while actual operations on variables 
is left to the vtable methods attached to the variables.

I expect things to get mildly incestuous for speed reasons, but I'm OK with 
that. :)

>I don't how
>typical is OO programming in Perl, but in Python that plays a central role,
>if your long run goal is to compile to native code you should have
>a "hard-wired" concept of classes and them like,

Yep. There's a fast "get name of object's class" and "get pointer to 
object's class stash/variable table/methods/subs/<insert generic class 
terminology here>".

>  because an operation
>like getting the class of an instance should be as direct and fast as possible
>if you want to use any of the "nice" optimization for a VM for a OO dynamic
>language:
>   inline polymorphic caches

Yup. I'm leaning towards a class based cache for inherited methods and 
suchlike things, but I'm not sure that's sufficient if we're going to have 
objects whose inheritance tree is handled on a per-object basis.

>   customization

Details? I'm not sure what you're talking about here.

>   or if/when possible: direct inlining.

Yep, though the potential to mess with a class' methods at runtime tends to 
shoot this one down. (Perl's got similar issues with this, plus a few extra 
real nasty optimizer killers) I'm pondering a "check_if_changed" branch 
opcode that'll check a method/function/sub's definition to see if it's 
changed since the code was generated, and do the inline stuff if it hasn't. 
Though that still limits what you can do with code motion and other 
optimizations.

>If any of the high-level OO system can not be used, you have to choose
>a lower level one and map these to it,
>a vtable bytecode mapping model is too underspecified.

Oh, sure, saying "vtable bytecode mapping model" is an awful lot like 
saying "procedural language"--it's informative without actually being 
useful... :)

					Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
dan@sidhe.org                         have teddy bears and even
                                      teddy bears get drunk