[Interpreter] Unused opcode handling needs fixing

[andymcca]

https://github.com/libretro/gpsp/blob/541adc9e1c6c9328c07058659594d6300ae0fa19/cpu.c#L3190

In the Interpreter, the handling of these ARM opcodes can only be included if HAVE_UNUSED is specified at compile time. Even then, the handling doesn't work because there is no code to move on to the next instruction. It should be something like this -

case 0xC0 ... 0xEF: { /* coprocessor instructions, reserved on GBA */ arm_next_instruction(); break; }

@davidgfnet do you agree? The dynarecs don't have this issue because they don't process the instructions in a loop, and the program counter is moved forward regardless at the end of the Switch/Case.

I'm still debugging DemiKids Light at the moment and found this issue whilst working on it - unfortunately changing it doesn't fix DemiKids but it does stop an endless loop when DemiKids issues an invalid ARM instruction!

[davidgfnet]

Unfortunately invalid opcodes cannot be just "skipped" or ignored. Theoretically, an invalid instruction should generate an INVALID IRQ that can be handled by the BIOS. (Also note that the definition of invalid is quite open since the GBA accepts some opcodes that are theoretically forbidden by the ARM spec). This is however pointless since the GBA BIOS blocks on said IRQ, it will just attempt to trigger some debugging stuff that is not present on the retail devices and "hang". We could handle the illegal opcode by terminating the emulation somehow (not sure if libretro supports this, I assume it might), and perhaps printing some useful messages. For the dynarec it's a bit harder, since it's OK for the dynarec to generate a lot of invalid opcodes (say some never-taken branch to "garbage" code), so adding this print/trap would require runtime support. Anyway not sure how valuable this is, since no "good" game should ever encounter an invalid opcode. This is just for our (developer) convenience. On that note I checked a few games with this issue and already found a couple of bugs. Thanks!

[andymcca]

No problem, and again, thanks for the explanations, it helps greatly for my understanding. My observation was that the invalid ARM opcode was issued during an Interrupt, but when I get back to it I'll actually get the PC and Opcode

[andymcca]

Didn't mean to close - clumsy phone fingers!