I took a look at the instruction emulation routines as compiled for IRIX by SGI's MIPSPRO compilers, trying to see if there was anything I could tweak to improve speed. There wasn't much: the SGI compilers do an awesome job of inlining direct-mode mac memory references and optimizing the resulting code. But here are a few suggestions which might help out the compilers for MIPS, Sparc, and other RISC-style platforms. I haven't tried them out (or even completely determined that they're feasible), so consider them food for thought:
- Pretty much every instruction increments the PC, which requires fetching and storing its value. You could save a few instructions by passing the PC as an argument to each op_xxx function, and returning the new PC value from it. The "canonical" location (regs.pc_p) would have to be updated before anything besides the op_xxx functions tried tor read it. I don't know if any code called from a signal handler cares about pc_p... that would be a problem.
- On platforms which require several instructions to construct the addresses of items in the static data area (like the regs and regflags arrays), it may be helpful to pass the address(es) of these arrays as parameters, instead of accessing them as globals. (Of course, of m68k_run_1 grows by an equal amount as a result, you haven't gained much.... You'd need to see what the compilers you're interested in actually generate for each case.)
- One really big source of (potentially useless) host instructions in the op_xxx routines is setting the condition codes. Several architectures have inline assembly language handlers to optimize this step. But for those which don't (unfortunately the SGI compilers don't support inline assembly language), it could potentially be sped up by storing the results of operations in temporary buffers, and only calculating the actual flag values from those buffers when they are needed. For instance, the Z flag only records that a value is zero, and the N flag records that its high bit is set. Rather than doing the tests in each instruction, just store the value to be tested. The V and C flags are more complicated, since they require comparing several values. But they're set a lot less often than N and Z.
Ideas? Responses?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
For the SPARC platform, I onced performed assignment of critical variables to global registers. regs.pc_p, regflags, and the functbl variables each used a SPARC global register for the whole duration of the program. The boost was up to 67%, if I remember correctly.
Is there any MIPS register which retains its value accross function calls ? If so, you should give it a try. Hmm, let me find out the sources for the SPARC version.
- About passing addresses through registers
I think a simpler way is to keep "all" UAE variables in a big struct, a CPU context, and pass a pointer to in a parameter to an op_XXX handler. Therefore, time to compute the address of global variables (use of sethi/or for SPARC) would be eliminated.
I also once did a similar thing in one of my experiments with UAE ;-)
- About deferred flag calculation
I read about that in a paper about Shade or Embra. There are possibilities for add/sub instructions but they require to keep three values: source register value, dest register initial value and computation result. Deferred flag calculation would work for those instructions but what about the handling of X flag ? I also think there are instructions taht can't be handled through a deferred flag calculation scheme.
A solution: dynamic compilation
- to synthetic instructions like in Executor
- to native code
where we can easily do live flag analysis.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I took a look at the instruction emulation routines as compiled for IRIX by SGI's MIPSPRO compilers, trying to see if there was anything I could tweak to improve speed. There wasn't much: the SGI compilers do an awesome job of inlining direct-mode mac memory references and optimizing the resulting code. But here are a few suggestions which might help out the compilers for MIPS, Sparc, and other RISC-style platforms. I haven't tried them out (or even completely determined that they're feasible), so consider them food for thought:
- Pretty much every instruction increments the PC, which requires fetching and storing its value. You could save a few instructions by passing the PC as an argument to each op_xxx function, and returning the new PC value from it. The "canonical" location (regs.pc_p) would have to be updated before anything besides the op_xxx functions tried tor read it. I don't know if any code called from a signal handler cares about pc_p... that would be a problem.
- On platforms which require several instructions to construct the addresses of items in the static data area (like the regs and regflags arrays), it may be helpful to pass the address(es) of these arrays as parameters, instead of accessing them as globals. (Of course, of m68k_run_1 grows by an equal amount as a result, you haven't gained much.... You'd need to see what the compilers you're interested in actually generate for each case.)
- One really big source of (potentially useless) host instructions in the op_xxx routines is setting the condition codes. Several architectures have inline assembly language handlers to optimize this step. But for those which don't (unfortunately the SGI compilers don't support inline assembly language), it could potentially be sped up by storing the results of operations in temporary buffers, and only calculating the actual flag values from those buffers when they are needed. For instance, the Z flag only records that a value is zero, and the N flag records that its high bit is set. Rather than doing the tests in each instruction, just store the value to be tested. The V and C flags are more complicated, since they require comparing several values. But they're set a lot less often than N and Z.
Ideas? Responses?
- About fast incrementation of the PC.
For the SPARC platform, I onced performed assignment of critical variables to global registers. regs.pc_p, regflags, and the functbl variables each used a SPARC global register for the whole duration of the program. The boost was up to 67%, if I remember correctly.
Is there any MIPS register which retains its value accross function calls ? If so, you should give it a try. Hmm, let me find out the sources for the SPARC version.
- About passing addresses through registers
I think a simpler way is to keep "all" UAE variables in a big struct, a CPU context, and pass a pointer to in a parameter to an op_XXX handler. Therefore, time to compute the address of global variables (use of sethi/or for SPARC) would be eliminated.
I also once did a similar thing in one of my experiments with UAE ;-)
- About deferred flag calculation
I read about that in a paper about Shade or Embra. There are possibilities for add/sub instructions but they require to keep three values: source register value, dest register initial value and computation result. Deferred flag calculation would work for those instructions but what about the handling of X flag ? I also think there are instructions taht can't be handled through a deferred flag calculation scheme.
A solution: dynamic compilation
- to synthetic instructions like in Executor
- to native code
where we can easily do live flag analysis.