PPSSPP for Windows Phone (8)?

[Dissonance]

Sorry to bump an old (and tired) thread/subject. But I haven't seen a proper technical discussion as to how EmiPSX was possible on Windows Phone (and it does actually run on Lumia 520 albeit not as well). Hopefully this will spur a bit of debate rather than the usual entrenched opinion I keep reading along the lines of "can't execute data so emulation can't be done except with a standard interpreter", which is just plain wrong.

I believe (based on conversations with the author) that EmiPSX uses threaded interpretation to achieve the necessary performance to run on a Windows Phone. In basic terms this works by creating an array of function pointers indexed by the program counter which is populated and updated as code is interpretted (much like a JIT would). Each time an instruction is decoded through the interpreter's standard fetch/decode a function pointer to the decoded instruction is cached. When the same address is called again the emulator skips the decode and calls straight into the appropriate instruction code. The idea being that frequently run portions of the code become "threaded" (a contiguous sequence of subroutine calls) rather than a sequences of pipeline disrupting conditional branches (as done in a typical interpreter's cascaded decode of an instruction). Threaded interpretation does not require data to be executed, only that data members be able to point to executable code (which is allowed in Windows Phone). Obviously threaded code is less efficient than a dynamic binary translation of a basic block due to the call overhead but it does offer a drastic improvement over a pure interpreter.

Now I'm not expecting this to persuade PPSSPP's developers to go ahead and attempt a port to Windows Phone, but I would be interested in a discussion of the relative performance gains to be had from threaded interpretation and I do consider EmiPSX to be a sound proof of concept for 5th gen console emulation on Windows Phone and RT platforms. By the way I have a background in development of soft-core processors and most of the code I write day to day is assembly or HDL of one flavor or another, so you can go ahead and use big words.