Re: Mockingboard emulator (was: Late night musings...)

[jefbla@bconnex.net (Jeff Blakeney)]

nparker@cie-2.uoregon.edu (Neil Parker) wrote:

>In article <50itqc$9bt@news.bconnex.net> jefbla@bconnex.net (Jeff Blakeney)
>writes:
>>[...]
>>I was thinking along the lines of "dissassembling" the code opcode by
>>opcode and checking to see if that instruction will cause an access to
>>a special area, such as the slots or softswitches, or is a branch or
>>jump instruction.

>My instincts are shouting at me, "This is *not* the right way to do it."

[some very good points snipped]

>Therefore, my instincts say as long as you're "disassembling" everything
>far enough to fully safety-check all the memory references, you might as
>well just do all the work in the initial "disassembly" step, and completely
>forget about filling and executing the execution buffer.

You may be right about this.  The more I've been thinking and talking
about it, there seems to be a lot more work involved with my execution
buffer method.  I'm just not sure yet exactly how much safety-checking
will be required.  If there are a large enough percentage of
instructions that I can simply copy to the execution buffer, then I
still think this method would have a chance.

I have to actually start checking each instruction and addressing mode
before I'll even have the percentage down.  Once I do, then I can make
a more informed guess as to its possible performance.

>>I'm now thinking that I will have to develop three different emulators
>>concurrently until I can declare one an absolute winner in the
>>execution speed department.  That way I don't need to keep guessing.

>If I were to bet on the outcome of that race, my money would be on the
>interpret-then-execute method to come in last.  In an earlier post I picked
>the straight interpretation method to beat the old-monitor-step/trace
>method...I'm no longer quite so sure about that, but I still think I'm
>leaning toward straight interpretation.

Like I said, I'll have to do some more work before I can give any
better estimates of execution speeds.