Corgi3DS has many CPUs to emulate: two/four ARM11 cores, an ARM9, and a Teak DSP. You can imagine how slow emulating all this on an interpreter is.
Normally, I would use dynarmic for the ARM CPUs (no Teak JIT exists, so it would have to be custom-made). There are some issues with that plan:
dynarmic only handles user mode. This is sufficient for HLE emulators like Citra and yuzu, but because Corgi3DS is LLE, it has to handle the various privileged modes, which each have their own register banks.
Piggybacking off the above issue, Kernel11 requires tight synchronization whenever it does anything related to the timers (svcSleepThread, svcGetSystemTick, etc). Ignoring any fancy pattern searching, this implies that we must fallback to interpreter when in supervisor mode.
dynarmic does not emulate ARMv5 architectures, which the ARM9 implements. This may not be an issue at all, however.
I am unsure how dynarmic handles the ARM MMU. Applications such as 3dslinux abuse the MMU pretty heavily, so having an accurate MMU is important.
If all of those issues can be resolved, then I will be happy to use dynarmic. Otherwise, we will need to make our own ARM JIT.
Corgi3DS has many CPUs to emulate: two/four ARM11 cores, an ARM9, and a Teak DSP. You can imagine how slow emulating all this on an interpreter is.
Normally, I would use dynarmic for the ARM CPUs (no Teak JIT exists, so it would have to be custom-made). There are some issues with that plan:
If all of those issues can be resolved, then I will be happy to use dynarmic. Otherwise, we will need to make our own ARM JIT.