Re: deferred vtable assignment?
Dan Sugalski wrote: What if the decision in-vtable or not-in-vtable is deferred? That's doable, I think, though I can see some issues. how about a two-tiered vtable, where a single high bit, if set, indicates extended handling, or at least consultation of a different table. I guess that amounts to the same as having a set number of extended entries that indicate check elsewhere to decide what do do now. Which again causes mind-expoloding possibilities, except that there is no reason to keep all possibilities in mind, just open up the pandorabox and let all the evil out. teddy bears get drunk and they all say yodelahihu
Re: deferred vtable assignment?
At 03:02 PM 4/26/2001 -0500, David L. Nicol wrote: Dan Sugalski wrote: What if the decision in-vtable or not-in-vtable is deferred? That's doable, I think, though I can see some issues. how about a two-tiered vtable, where a single high bit, if set, indicates extended handling, or at least consultation of a different table. I guess that amounts to the same as having a set number of extended entries that indicate check elsewhere to decide what do do now. Yeah, I think this might be what we do, but there are still issues. I'd rather know at runtime (or, rather, after BEGIN time) what I've got handy for vtable entries, since it's at that point that the vtable messiness will be finalized as the bytecode hits the optimizer. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: deferred vtable assignment?
At 05:14 PM 4/25/2001 -0500, David L. Nicol wrote: Dan Sugalski wrote: 2) Anyway, even resizing vtables we would need some more indirection to determine in which position of the vtable is which operator. No. Each operator goes in a fixed position in the vtable, and it's the same for each table. Anything else is nasty, error prone, and slow. What if the decision in-vtable or not-in-vtable is deferred? The size of the vtable could be chosen late in the compilation. There could be hints. That's doable, I think, though I can see some issues. It means that the bytecode compiler will need to do some reorganization and possibly emit different opcode streams. That's not a huge issue, but it does mean that we'll need to do extra processing of bytecode-compiled modules. (Especially ones loaded at runtime, unless we restrict the module compilation sequence to not use extra vtable entries, or spit out two streams of bytecode and choose which to use based on the number of remaining vtable entries) The logic could get potentially rather dodgy when twiddling code sequences from one way to the other. I'd really just as soon not deal with the issue this way, though that doesn't mean it won't be the way we end up going. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
deferred vtable assignment?
Dan Sugalski wrote: 2) Anyway, even resizing vtables we would need some more indirection to determine in which position of the vtable is which operator. No. Each operator goes in a fixed position in the vtable, and it's the same for each table. Anything else is nasty, error prone, and slow. What if the decision in-vtable or not-in-vtable is deferred? The size of the vtable could be chosen late in the compilation. There could be hints. I am right now imagining vtable slots analogous to register entries for data in a C function. That we we also can deal with the aliasing of comparison operators to a variety of cmp/== (or not) on a case-by-case basis. if it is supposed to be an optimization, keep it an optimization, with a fall-back to a non-optimized paradigm. -- David Nicol 816.235.1187 [EMAIL PROTECTED] and they all say yodelahihu
