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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4