Thanks for the link.
I'm curious about your goals and expectations regarding this project. I've been a pretty vocal detractor to the approach for various reasons; for GPAdvance in particular this line from the 1.47 changelog basically sums it up:
"- cache is disabled (poor performances but better compatibility)"
It's difficult to determine exactly what percentage of games can run OK without violating cache coherency in ARM9. The problem comes from code loaded from ROM and stored in IWRAM to be executed more quickly. This by itself isn't automatically an issue since ARM9's cache is not write allocating. You expect that code that gets loaded into data cache then written to a different location will leave data cache, and hence get properly loaded into instruction cache when it's executed. The problem probably comes when new code is loaded that either overwrites old code or is added near old code (same cache line) such that part of instruction cache becomes stale. The problem will also happen if the code that's written to is already in data cache for some reason. Finally, actual self modifying code will almost always pose a problem, and GBA games do resort to self modifying code if not somewhat infrequently.
Whatever the actual causes of the problem, we know that it was enough of a big deal for them to turn off cache despite GPAdvance still being fairly early in development and having a lot of other compatibility inhibitors. With cache disabled RISC CPUs an ARM9 will be really slow - one test has shown a 200MHz GP2X to give a Dhyrstone score of only 3DMIPS, a figure down from ~200 with cache on.
If given a choice between virtualization with cache disabled and a recompiler I'd definitely go with the latter, and not just for performance reasons. Virtualization inhibits clock counting, so if you're on a platform that can't naturally sustain real-time performance by a wide margin then you're liable to start causing crashes instead of just slow emulation.
The other problem is that GPAdvance is using video emulation code from VBA, which is very slow. For most games you would have to have a very high frameskip to negate this. Of course, on a 90MHz ARM9 you'd struggle with rendering performance no matter how efficient the code was.
