Michael, On Oct 25, 2007, at 8:45 PM, Michael FIG wrote:
typedef oop (*_imp_t)(oop v__closure, oop v_stateful_self, oop v_self, int argc, ...);
Something like this is highly desirable, just like the splitting of self and state into two selves and making information about the method available to it through the closure. I'm sure better solutions for all of these can be found, solutions that do not depend on information being passed redundantly in the vast majority of sends. I'm still unhappy about all two (or three ;) additional arguments beyond the original 'self'.
Off the top of my head, it might be better to extend the ABI with global (read: thread-local) 'variables' (read: registers) that contain this information for use when required, with minimal (if any) overhead when ignored. Here's how I might do it:
'_closure' is a by-product of method lookup. It could be computed in a global (thread-local) register and saved into (and referred to through) a temporary by all method prologues that refer to their '_closure'. (The register wouldn't have to be thread-local if context switch could be guaranteed not to occur between _send and the end of the destination method prologue.)
_stateful_self is trickier, having the same dynamic and LIFO behaviour as 'self' in those rare cases we care about it. I can't think of any simple way to manage it independently of the arguments. (Various twisted schemes that store it in the _closure, duplicating the closures each time the two selves diverge, might be possible but the tradeoffs involved seem wrong.) In contrast to '_closure', whether to diverge 'selves' is a choice made explicitly by the sending method (not information gathered implicitly by the execution machinery) and every method must potentially be prepared to deal with 'self ~= state'.
Of the two, 'argc' most closely resembles '_closure' in its behaviour: it's computed during every send, determined implicitly by the execution machinery rather than imposed on the destination by the sender, and ignored in the vast majority of methods. Saving it in a global register variable seems the right thing to do; the overhead of passing it to every method seems wrong (just like it does with _closure).
So rather than adding 'argc' to the implicit arguments in the signature of every method, I'd be tempted to remove '_closure' from the implicit args and build a different mechanism to supply both '_closure' and 'argc' (and anything else you cannot predict needing beforehand) to just those methods that care about them. A first approximation could probably be done trivially, and safely, by saving this information in a thread-local variable.
More elaborate schemes are certainly possible, but depend on having knowledge of which methods are variadic. This knowledge is neither imposed on senders before they can pass additional arguments nor communicated between the object/message and the function universes. Earlier today I mentioned selectors should be more intelligent than just a symbol; knowing whether their implementers and senders need to worry about variadic arguments is one of the things they could tell you, at both compile- and run-time.
The next stage would be to patch GCC so that it provides an integer macro for the number of variadic arguments supplied to a variadic macro, and update the _send macro to use it, something like:
Or you could just pass that as an explicit argument to _send(). The Id compiler knows how many arguments you supply in each send, and will happily provide the information to the runtime.
If you agree with this design, I would be more than happy to implement it and submit the relevant patches.
I'm not keen on adding things. I'm a huge fan of taking things out. If you can take _closure out of the method arguments without breaking anything in object/examples/*, function/* and function/examples/*, I'd suck up the diffs in a nanosecond and then happily apply a second set of diffs that make 'argc' (or some better name) available alongside '_closure' to methods that care about it and/or use '...' to recover anonymous args.
Cheers, Ian _______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
