> I think the overhead of code generation and memory management (the basic block
> hash table) might outweigh the key dynarec benefit of eliminating the
> fetch/decode loop, especially with a CPU like the SNES's. You'll also have to
> keep strict account of timing, which is possible in a dynarec, but could get
> messy depending on whether or not you can simply do the timing on a per-basic
> block basis.
> I would say you ought to profile first. Premature optimization is often a
> complete waste of time. You need to know what to optimize first. It may be that
> the CPU isn't the bottleneck. I'm sure that the solution will ultimately require
> a healthy dose of assembly language in all major components of the emulator
> (CPU, graphics, sound, etc.) The SNES CPU is fairly simple and given the MIPS'
> large register file, you should be able to write a pretty nice CPU core.
> Fetch/decode might be a bit messy, as will flags, but you can probably store
> everything in the registers and minimize memory overhead.
As always Bart I enjoy your replies as you seem to genuinely enjoy taking time off to respond to these types of inquiries.
I had thought of the profiler but I was wondering if profiling on the PC might have different results compared to execution on the PSP. Probably nothing huge and I'm sure it's a great indicator either way. Could you recommend any?
I'll look into that and assembly for the PSP. I'm not a stranger to hardware architecture or assembly but it's been a while and it was only x86. I'm sure I'll have to play with it for a bit before I even feel comfortable building a CPU core. Either way I'm always looking for something fun to program and I've squeezed out enough fun with Java, .NET, PHP and so forth. Time to get dirty with the low level stuff again.