'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
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
