At 03:40 PM 6/12/2001 -0700, Damien Neil wrote:
>On Tue, Jun 12, 2001 at 06:12:35PM -0400, Dan Sugalski wrote:
> > 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?
>
>I'd say that choosing the more complicated way because it seems to
>be faster is almost always a bad idea. What was that quote about
>premature optimization?
What, you mean the one that's not relevant here? :) Quick sort's more
complex than bubble sort, but you don't generally find someone arguing
against it on the basis of its complexity.
Granted this isn't as much an algorithm issue as an implementation one, but
it is pretty fundamental--is our op loop fast and simple, or less fast and
complex?
>A major advantage to putting the decoding in the main loop to start
>with, at least, is that it makes it easier to perform major surgery
>on the overall opcode design without needing to touch every op.
>I don't know how likely such surgery is.
This is definitely a plus, but I'm not ultimately sure it's a big enough one.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
