Apologies if this is in the wrong section.
First of all, the rest of this post is kind of irrelevant depending on the answer to this question:
Does the debugger (accessible via passing "/d" at the command line) use the recompiler core and/or have the ability to? I am guessing it doesn't because the emulator slows from ~700% speed to ~10% for a particular test case. Also I imagine there aren't a whole lot, if any, emulators that have debuggers that don't run with an interpreter core (it's just silly not to...maybe).
If it doesn't use the recompiler or have the ability to, I would like to add support for this. I don't want it to be sloppy either; I want to do a good job and come up with something clean for everyone to use, not just some hack only I would get any use from.
Unfortunately if I am going to do this I need more information about how the emulator does breakpoints to begin with and how I could feasibly get recompiled code to pass "messages" from the context of emulation to the debugging UI. I have figured some stuff out from poking around in the "Core" project of the solution (some of which is why I am not sure debugging can't be done with the dynarec, although I only saw a call to CCPU::Break() in the interpreter core) but I think it would go a lot faster (and the result would better conform to the project's standards) if I had someone more knowledgeable about the emulator's internal workings to give me some tips.
As for how insane the idea is, my logic is basically that the slowdown from adding extra instructions in with every recompiled load and store opcode for determining if there is a hit (which might not even have to be inlined) won't be enough to make debugging with the recompiler core less favorable to debugging with the interpreter core. Of course this doesn't address the real insanity: meta instructions embedded in recompiled code and having them report collisions, not to mention the difficulty in breaking on an exact instruction due to the code being recompiled and not interpreted. My plan was to go for an approximate breakpoint; it doesn't have to be exact to be useful, but I'd hate to have a modularity nightmare result. So once again, I think it'd be good to have an expert analysis of the idea.
First of all, the rest of this post is kind of irrelevant depending on the answer to this question:
Does the debugger (accessible via passing "/d" at the command line) use the recompiler core and/or have the ability to? I am guessing it doesn't because the emulator slows from ~700% speed to ~10% for a particular test case. Also I imagine there aren't a whole lot, if any, emulators that have debuggers that don't run with an interpreter core (it's just silly not to...maybe).
If it doesn't use the recompiler or have the ability to, I would like to add support for this. I don't want it to be sloppy either; I want to do a good job and come up with something clean for everyone to use, not just some hack only I would get any use from.
Unfortunately if I am going to do this I need more information about how the emulator does breakpoints to begin with and how I could feasibly get recompiled code to pass "messages" from the context of emulation to the debugging UI. I have figured some stuff out from poking around in the "Core" project of the solution (some of which is why I am not sure debugging can't be done with the dynarec, although I only saw a call to CCPU::Break() in the interpreter core) but I think it would go a lot faster (and the result would better conform to the project's standards) if I had someone more knowledgeable about the emulator's internal workings to give me some tips.
As for how insane the idea is, my logic is basically that the slowdown from adding extra instructions in with every recompiled load and store opcode for determining if there is a hit (which might not even have to be inlined) won't be enough to make debugging with the recompiler core less favorable to debugging with the interpreter core. Of course this doesn't address the real insanity: meta instructions embedded in recompiled code and having them report collisions, not to mention the difficulty in breaking on an exact instruction due to the code being recompiled and not interpreted. My plan was to go for an approximate breakpoint; it doesn't have to be exact to be useful, but I'd hate to have a modularity nightmare result. So once again, I think it'd be good to have an expert analysis of the idea.