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

[nparker@cie-2.uoregon.edu (Neil Parker)]

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.  If the instruction is NOT one of the above, it
>would be placed into an "execution" buffer and the next instruction
>would be checked.  If the instruction IS one of the above, then it is
>left out of the execution buffer, a return from subroutine is placed
>at the end of the execution buffer and the buffer gets executed.

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

In order to get the information you need out of the "disassembly" step,
you're going to have to interpret each opcode at least far enough to figure
what its addressing mode is.  If you then want to safety-check the various
indexed addressing modes, you'll also have to interpret it far enough to
discover what changes it makes to the registers and to page zero.

Consider what you know about the opcode at this point.  You know what the
opcode is, and what its addressing mode is, and what effects it has on
the register and on memory.  For many opcodes, this means you've fully
interpreted the opcode.  Executing the opcode directly in the execution
buffer would then be superfluous and a waste of time (even if it does run
at full host processor speed), since you already know what its effect is
going to be.

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.

>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.

              - Neil Parker
-- 
Neil Parker                       | No cute quote, no cute ASCII art, no cute
nparker@cie-2.uoregon.edu         | disclaimer, no deposit, no return....
nparker@cie.uoregon.edu           | (This space intentionally left blank:
http://cie-2.uoregon.edu/~nparker |                                           )