The current calling conventions are optimized for the case where the caller knows that that a call is being made. Works well for that, and I'm relatively happy with how things are functioning. (Nothing's perfect, alas) The current convention falls down badly when more restricted or top-level calls--that is, calls that have a very restricted calling convention or look like there is no parent bytecode,. Both vtable and opcode functions fall into this category.
So. Two options. We can have horribly slow calls into bytecode that implement vtable and opcode functions. Or we can have alternative calling conventions for 'special' functions. (No, "alter the normal calling conventions" isn't an option :)
Personally I'm up for alternative calling conventions in this case. These functions *are* special, and treating them as such isn't unwarranted. There's stuff that can't happen, like having continuations escape, and returns exit a runloop rather than just transferring bytecode control. There's no ambiguity or runtime setting of inbound parameters either--parameters are fixed and known at compiletime. As such, I'm thinking that it's fine to strip things down a lot.
With that in mind, I'm up for some discussion of how to make these look, and how the subs should behave WRT calling in and returning things. So... go for it, and lets get this out of the way so we can implement it for 0.1.1 and speed up objects just the tiniest bit. :)
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
