Emulator Issues #5864
closed
CMP/Bcc merging might miss executing CMP when an exception occurs
0%
Description
- Game Name and ID:
Tales of Symphonia, GQSFAF
- What is the issue?
The game will crash a few seconds after entering Flanoir. The time it takes to crash can vary.
- Did the game ever work correctly on an
earlier version of dolphin?
This issue does not occur on 3.0 (x64).
4) What steps will reproduce the problem?
1.Enter the town of Flanoir.
2.Wait for a little while.
Errors such as 'BackPatch - no support for operand size 1' and 'Unhandled disasm case in write handler' will appear.
- What version of dolphin are you using. On what
operating system, drivers, and hardware?
I'm using 3.5 (x64) and have also tried 3.5-108 (x64) to no avail.
OS:
Windows 7
Hardware:
i5-2500k (stock)
560ti
Updated by delroth almost 12 years ago
- Status changed from New to Accepted
- Issue type set to Bug
- Priority set to Normal
Please provide a memory card with a save just outside of the city. Confirming this bug - I've seen a lot of reports on the forums.
Updated by m.kara92 almost 12 years ago
I'm having issues attaching a file through Google Code thus I uploaded it through Sendspace : http://www.sendspace.com/file/05gn4c
My savefile is for the PAL French only version which might not work on the US or PAL English only version, nonetheless I hope this can help.
Updated by delroth almost 12 years ago
Yeah, if someone has a NTSC US save just outside of Flanoir and could attach it here, it would make things much easier for me (I have the NTSC version dumped, not the PAL version).
Updated by m.kara92 almost 12 years ago
A person in the forums seems to have posted his savefile, presumably for the US version.
http://forums.dolphin-emu.org/Thread-gc-tales-of-symphonia--25820?page=7 Post: #70
Updated by delroth almost 12 years ago
- Status changed from Accepted to Work started
- Operating system N/A added
Could you try this build and tell me if the crashes still happen?
http://dl.dolphin-emu.org/wips/delroth-dolphin-master-3.5-135%2b-x64.7z
Updated by m.kara92 almost 12 years ago
I was able to explore Flanoir without any crashes thanks to your work, you have my gratitude.
I also observed erratic framerate in Flanoir (only on LLE) which doesn't seem to happen in any other part of the game, I'm assuming that this is a simple matter of hardware performance.
Thank you for your great work.
Updated by delroth almost 12 years ago
- Priority changed from Normal to High
- Category set to ppc
Ok, this is only the first step towards a fix though: the current patch removes an optimization in the JIT which causes that issue.
The issue, as I understand it:
- The game executes a loop for (i = 0; i < 0x1000; ++i) { ... } which does not modify i at all.
- The loop condition is translated to "addi , , 1; ...; cmpwi , 0x1000; ...; bne loop_again". Note the "...": there are instructions between the cmpwi and the bne.
- PPCAnalyst moves the cmpwi to just before the bne because this is the first instruction that depends on the flags or modify i.
- One of the instructions between cmpwi and bne raises an interrupt (GP write -> FIFO interrupt, I guess). In that case, the cmpwi was not executed because it was moved.
- When we come back to the loop after the interrupt occurred, we are in a new block starting after the cmpwi. That means the cmpwi will not be executed at all.
Knowing that, some ideas to fix this:
- Do not move a cmp after an instruction that might raise an interrupt. Might be hard to detect, especially when MMU is enabled and DSI can happen at every load. This will also make this optimization less effective.
- When we raise an interrupt, if there is a cmp pending (how to detect that?) execute it before interrupting.
- When we moved a PPC instruction, memorize that and insert the moved instruction to every other PPC block that might need it. This will force us to handle tricky cases due to possibly jumping inside a block (in this case we don't want a cmp from before our jump addr to be inserted).
Fix 1 is the easiest to implement. Fix 2 could maybe work but I'm not sure how easy it is to implement (maybe put that in CheckExceptions?). Fix 3 could work too, will keep all the performance wins of moving cmp but might be hard to implement due to tricky cases.
Cc-ing skid, I'd like to have your opinion on that issue.
Updated by nintendonerd1889 almost 12 years ago
@delroth, I sent my brother the build and I await his response, as well as suggesting he not use save states, but the actual memory card instead. This is the_randomizer from the Dolphin forums.
Updated by delroth almost 12 years ago
- Status changed from Work started to Fixed
A smarter fix seems very difficult to implement correctly for a very small performance improvement (I could not measure a performance decrease with my workaround). Moreover, this workaround fixed more games than expected: at least MMU games crashing at boot before this fix are now booting properly (yay!).
Closing as fixed.