Additionally: - Floating point issues. Sure both the host and guest implement IEEE 754 floating point math, but that only helps if the emulated cpu is in IEEE

Additionally: - Floating point issues. Sure both the host and guest implement IEEE 754 floating point math, but that only helps if the emulated cpu is in IEEE 754 compliant mode (which it never is, because it's 754 compliant mode is slower) and only uses instructions supplied by 754 (which they don't because plenty are missing, like FMA, SIN/COS, SQRT). PCSX2 gets this particularly bad, because the PS2's vector units don't even try to implement proper IEEE 754 math and they have about 5 different workarounds to try to make different games work. But even Dolphin runs into issues trying to emulate PowerPC's non-compliant mode. Denormals are now handled correctly, but we still have issues with NANs. - Unified GPU/CPU memory. The gamecube only has one 24mb block of memory, with both textures and code in it, which is the complete opposite of what the host GPU wants. So we have a huge amount of texture cache code to yank textures out of the unified memory and convert/upload them to the GPU, then make sure we know when the texture has changed so we can re-upload it. Things get even more complex when the game starts coping things back to into the unified memory. In some games end up hash about 12gb of textures every second to make sure they haven't changed. - Interrupts. So you have jitted your code, what happens when you need to fire an interrupt in the middle of a block? - Timing. To simplify emulation, you might say that an operation (like loading from the DVD, or rendering a polygon) will complete instantly, which works for most games, until you find one which never expected the result to return that early and crashes or glitches. These issues can be a complete nightmare to debug, and even if you do work out which operation is too fast you have no idea how long that operation is actually meant to take without doing tests on the hardware.