At 04:32 PM 8/2/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. A question: when you say variable you mean variable (perl sense of that) or object. It has already been pointed out but it's really confusing from the point of view of python terminology. Will perl6 have only variables which contain objects, truly references to objects like Python or ...?

Well, it sort of looks like: name--->variable--->value The name is a symbol table entry that points to the variable. The variable is a data structure that has the vtable info, some pointer data, some flags, and general whatnots. (The docs refer to this as a PMC, or Parrot Magic Cookie, FWIW. Which isn't much) The value is the actual contents. We also have to track properties on both a variable and a value basis. For example: declare c, b declare a is const = 0 but true b = a c = \a dereference(c) = 1 In this case, the variable represented by a has the property 'const', and a value of 0 which has the property 'true'. The assignment to b copies the value, and the properties on the value (true in this case), but not the properties on the variable, so b isn't const. c is a reference to the variable a represents, so the attempt to assign to the dereference of c will fail, since the variable c points to has the const property. We can't depend on the properties to be attached to the *name* a, since (in my crude attempt to use python-style blocking) the name a has gone out of scope by the time we dereference c, and so would any properties attached to the name as such. I think the variable here would correspond to a Python object, but I'll need to go digging into Python semantics more to be sure. Currently there's not a lot planned around the actual symbol table entry, since it's not required for variable existence, and there's not much I can think of to attach to it anyway. (References mean we can't use it for much, really) My bet, and this is just an off-hand thing, is that the parser would spit out bytecode tying the symbol table entry and the PMC structure more closely than it might for other languages. At least do a lot more symbolic fetch/store ops, if need be, which we might not.

I should repeat that your explanation that assigment is somehow performed calling a method on the "variable" is quiet a strange notion in general, I can imagine having a slot called on assigment that eventually does a copy or return just the object but assigment as an operation on the lvalue is something very peculiar. I know that perl5 assignment is an operator returning an lvalue, is this related?

I don't think so, but I'm betting we're talking terminologically cross-wise. Assume, for example, the following pseudoish code: declare kitchen isa Thermostat kitchen = 20 In this case the kitchen variable is active, and assigning to it changes the temperature the thermostat in the kitchen is set to. The magic properties aren't attached to the name per se, at least in perl--it's just a handy way to get the PMC that underlies the thing. I can get an indirect handle on the data that the name 'kitchen' refers to and update it that way, or if I have that handle the 'kitchen' name can go completely out of scope and the only way to refer to the object representing (and allowing control over) my kitchen temperature is via the handle I've got on what's now an anonymous object. (Or, if I'm feeling really wacky, have two or more names that look like separate things but actually all point to the same PMC structure) I think it's the potential existence of references (or pointers, or whatever you want to call them) that necessitate the three-level split. It sounds like the things I'm calling 'name' and 'variable' are much more tightly bound in Python. There are several reasons to call a PMC assignment operator, rather than just unconditionally slam a new PMC into the name slot: 1) In the kitchen example above, assigning 20 to kitchen doesn't suddenly make kitchen an integer variable--it needs to stay a Thermostat, and just do something because we assigned to it. (And I understand this might not be the way Python would do things, in which case Python variable vtables might just have an "overwrite myself with the incoming info" function, rather than allow it to be overridden) 2) Since we can't really assign properties like constant-ness to a name (in which case we could get a reference to a variable and bypass the properties on the name by referring to it by reference) that needs to be enforced in other ways. In this case with a custom assignment vtable function which pitches a fit if you try to alter the variable. 3) Some other thing or other I apparently can't think of. It's a really good reason, though.

...

...

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. Make sense for the interpreted version, but for speed call-site caches is far more promising when native compiling, but also more complicated. I imagine you already know e.g. the Self project literature.

Self I've not dug into. Despite all the "I haven't see that" that keeps popping up in my conversation, I *have* done a lot of research. (The pile of digested books at one point outweighed my kids. They've grown, but the new research pile's about to grow too...)

...

...

customization

Details? I'm not sure what you're talking about here. Compiling different versions of the same method for example wrt to the receiver type in single dispatch case. See below

Ah, aggressive inlining of a sort. I think. Yep, on the list of things to do with the optimizer. (Not on the first version, probably, but certainly later)

...

...

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... :)

I imagine you already know: especially when compiling to native code, it is all a matter of optimizing for the common case, and be prepared to be quiet slow otherwise, especially when dealing with dynamic changes, both in Perl and Python there is no clear distiction from normal ops and dynamic changes to methods... but in any case they are rare compared to the rest.

Yup. I am profoundly tempted, and I think it will go in, to have a "stable code" switch that can be given to the optimizer which guarantees that, once the compilation phase is done and we finally get to run for real, code will not change. And then apply all the advanced optimization techniques at that point.

Threading adds complexity to the problem.

Nah, not too badly. A little synchronization issue, but that's reasonably trivial.

For the rest is just speed vs. memory, customization is a clear example for that.

Sure. The one nice thing that both perl and python have going for them is the ultimate presence of all the source (or a high-enough level representation of it to feed to the optimizer) at run time. We can tell with more surety what side-effects various methods and functions in external code libraries will have, and we can get more aggressive (maybe) because of it. Unlike, say, C, where passing a pointer to a routine outside what the compiler can see will hobble the optimizer a whole lot in many cases... Dan --------------------------------------"it's like this"------------------- Dan Sugalski even samurai dan@sidhe.org have teddy bears and even teddy bears get drunk