Dan Sugalski <[EMAIL PROTECTED]> wrote:So, I'm doing these, because I need 'em, and we might as well get the things in now. For the record, these things will be called as functions (not methods), with three parameters, so the signature looks like:
A short question WRT implementation: shouldn't all MMD functions just use one function slot? You now seem to duplicate the whole table.
Yes, I do.
There are two ways I can see to do this. The first is to have some sort of unified table structure, which holds tagged entries, and the dispatch code checks the entries and dispatches. This'll take as much memory as we currently use. (Alternately the entries themselves can be larger, in which case the usage will be based on the sparseness of the table) It's also slower in all cases, since you're forced to do the flag check and dispatch and you've drastically lowered the cache coherency
The second way is to use the split table struct, which is what I did. Still have the check, but it's unified with the C function case so it takes a single word rather than two, which ups the cache density some. If I could've managed, I'd build up a real C function for each vtable entry in bytecode, but that's not portable, unfortunately. (I *really* wish C did currying...) I considered having an "Execute the vtable function in bytecode" generic function that got passed the X and Y to look up in the table and dispatch, but that adds a pair of parameters that're otherwise unneeded and that slows things down too.
Besides, this is all behind-the-scenes stuff--nothing external should know about the inside structure. If we want real efficiency we're going to need to compress the tables a lot better than we do now (since we don't actually compress the tables now). I've a paper on that which I'm trying to dig up an external reference for. (I'll post when I have it)
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
