Just to clarify for those less knowledgeable in software development why exactly WP is so hard to develop emulators for vs Android...
Originally Posted by link68759
Every emulator works by converting machine code instructions written for one system into another code, usually this is to the native instruction set of the platform the emulator is running on. So essentially a WP8 PS1 emulator is trying to convert MIPS instructions and calls to the PS1 BIOS into ARM machine code and DirectX calls. The simplest way to do this is an interpreter, it reads an instruction from the game's code then attempts to decode it, in the simplest case this would be a gigantic switch statement in C code.
Unfortunately this is very slow, many native instructions are being executed for a single game instruction. Many of these are caused by the overhead introduced by using a high level language like C. So the next step we can do is re-write our interpreter in native assembly language and get access to some instructions that may be available on our platform's CPU but not directly accessible from C code. However there will still be many more instructions executed per emulated instruction and needless to say writing a massive program in assembly language is not trivial, nor can it be ported to other architectures (e.g. x86 to ARM).
The final step which is actually so powerful that you can often skip using assembly and go straight for a C program is dynamic binary translation (also known as dynamic recompilation/dynarec or JIT/Just in Time compilation). In this case the emulator still has an interpreter but the emulator dynamically profiles the code, recording how often certain sections are run. The emulator also stores the eventual output of the interpreter (native machine code instructions). When the emulator detects it has run a piece of code before, it can skip the interpretter and just pull the stored native code from memory and execute that. The end result is a massive performance increase.
To give you some perspective. On a PC emulators for 8-bit systems like NES or SMS can be written using C, C++ or C# interpretters. 16-bit systems like SNES and Megadrive usually use assembly code interpreters. Anything newer like PS-1 has always used dynamic binary translation/dynarec to get the required performance.
Problem is that WinRT and WP8 apps cannot use dynarec because this technique requires that the program use self-modifying code. Why is this? It just so happens that self-modifying code is commonly used by viruses to conceal themselves. Android and jailbroken iphones allow self modifying code to be executed.
EDIT: I'm updating this post to reflect a minor breakthrough achieved for emulation on WP8. I neglected to mention there is a technique that falls in between pure interpretative emulation and dynamic binary translation called "threaded interpretation". In this method when an instruction is run by the interpreter the emulator caches a pointer to the decoded interpreter instruction. When it encounters that instruction again (i.e. the program counter address matches) the emulator can retrieve the pointer and jump directly to the decode instruction, the intervening series of operations to decode the instruction is avoided. In theory at least no self-modifying code is required since the emulator is just calling code that already existed elsewhere in the program. N.B. The technique is called "threaded" because it is essentially generating threaded code, not because it is multi-threaded.
What does this mean in terms of performance? Well it's still not going to be as fast as dynamic binary translation, because the emulator is still having to jump around the program every instruction as opposed to executing a big block of native code stored in memory. However this difference is extremely small in comparison to the gain over a traditional interpreter. Will it work on WP8? We don't know yet but Andre is trying this technique out on emiPSX so we'll have to see what happens...
TLDR WP8 cannot emulate games at the same speed as the same hardware running Android. But we may be able to get close...