'Kay, here's a question to ponder. Should the op dispatch loop handle argument decoding, or should that be left to the opcode functions? The upside to the functions handling the decoding is they can special-case it. makeref (a hypothetical "make a reference to a PMC" operator), for example, would know it always got two arguments and would be hardcoded to fetch them. The downside is that we'd constrain the functions to taking arguments in our virtual registers, since we wouldn't have any absolute machine addresses to hand to them. (If we did it'd mean that something was already doing the decoding) The upside to the dispatch loop doing the decoding is the opcode functions can get called with their parameters like normal 3GL functions, making calling them simpler. The downside to the dispatch loop decoding is speed--we can't special-case anything, since we don't know what the cases are, and that means a more general decoding scheme, which is pretty much guaranteed to be slower. At the moment I'm leaning towards the functions doing their own decoding, as it seems likely to be faster. (Though we'd be duplicating the decoding logic everywhere, and bigger's reasonably bad) Possibly mandating shadow functions for each opcode function, where the shadow does the decoding and calls the real functions which take real things rather than our registers. Opinions anyone? Dan --------------------------------------"it's like this"------------------- Dan Sugalski even samurai dan@sidhe.org have teddy bears and even teddy bears get drunkThread Next