> I always prefer reusable, flexible and easily maintained code so I'm on board
> with modeling this in C. I actually took some time the other day to parse
> Turbo68k to see what you had done there and saw what you described.
Avert your eyes from Turbo68K :) There should be better CPU cores based around this principle. IIRC, Neil Bradley's cores did it, and maybe A68K?
> foolish for asking but what executes the emitted code? They are just a set of
> strings, right?
It spits out assembly source code and you assemble it with NASM. It's not done at run-time, but at compile time as part of the build process. The idea is that there is going to be a lot (a LOT) of redundancy in the assembly code, so why not write once, and emit it over and over again?
You could argue that macros would help, and that's true, but you have way more flexibility with the emitter approach. Also, many instruction handlers are almost identical (the only difference is that they inline some of the register accesses) so it makes sense to generate them in an automated fashion rather than to re-type them by hand, even with macros. For example: for the 68K instructions involving at least one register, the emitter emits 8 unique instances or so (and sets up the jump table appropriately by pointing to each one) by decoding the 3-bit register field and hard-coding that read/write for each different register. That way, less of the instruction operands have to be decoded inside each function, speeding things up (although perhaps at the cost of cache performance -- A68K does less of this and runs faster.)
> I also saw a reference to some dude named Tyranid on your page.
> He seems to be big in the hacking/homebrew scene. He's a big player in the
> public SDK that was built for the PSP.
Yeah, I don't know the guy well, but he wrote a Saturn debugger which was pretty cool.
>SNES9x port for
> the PSP and I had planned on incrementally modifying it with code that's
> tailored for the PSP architecture.
That's not a bad idea. Isn't SNES9X fairly accurate? It sounds like you could modify quite a bit to get it up to speed.
> emulation may need some tweaks as there are glitches and there are certain
> effects that noticeably tax the PSP.
Graphics will be the hardest task, and will probably require several rewrites and some very clever ideas. It'll be more than just trying to beat the compiler's output by writing your own assembly code. Rather, it'll have to be about smart design as well as how you can leverage the PSP at the assembly language level when thinking up your design.
> Just to clarify, when you talk about passing the context of the CPU we're
> talking about something like a struct in the C world, right?
> the OO world I've been living in for the past 3 years to go back to the
> procedural ways of C/assembler. I'm glad that modular design is still available
> to some degree :-P
You can still use OO design principles.