GameBoy color emulator opcodes automation

I'm writting a GameBoy color emulator in C, just to introduce myself into this world, it is interpreted, nothing of dynamic or static recompilation :P

Now I'm right in the tedious task of implementing all the CPU opcodes in C code, I have to write all these: http://www.pastraiser.com/cpu/gameboy/gameboy_opcodes.html and I don't want to take them from another emulator.

The questio开发者_开发技巧n is, is there some way to automate the opcodes writting? Maybe it's a silly question and it will have a silly answer, but I want to work as less as possible. :)

I've done this kind of thing before and the way I did it was with macros, but doing it that way you end up with a whole lot of code duplication that overflows the cpu cache and makes things slow. If I were to do it today, I'd get rid of the whole "opcode switch/jumptable" idiom except for obscure/rare opcodes, and write common branchless code for all the normal arithmetic/logical ops using some small lookup tables based on the opcode number. Think something like:

operand1 = regs[operand1_table[opcode]];
operand2 = regs[operand2_table[opcode]];
res[ADD] = operand1+operand2;
res[SUB] = operand1-operand2;
res[OR] = operand1|operand2;
/* ... */
regs[dest_table[opcode]] = res[optype_table[opcode]];

This code is of course over-simplified, but can be expanded to deal with memory operands, etc. Also note that a jump instruction is just an add instruction with the program counter as one of its operands.

For CISC archs like Z80 (or the GB variant thereof) or x86, you're also going to have to deal with condition code flags. However they can be done as a second set of computations like the res[...] = ...; ones above.

I know this is an old and answered question, but for the record, if someone ends up having the same problem:

I made up a quick script to parse this documentation page and generate a JSON with opcodes description.

You can just load this JSON and generate the boilerplate of your GB [dis]assembler code from it, that should clearly save time since JSON is easy to manipulate from most scripting languages.

Code and resulting JSON:

• https://github.com/NewbiZ/gbemu/tree/master/scripts

That is why, so far, I have only done emulators or static recompilers for msp430, 6502, and thumb...less typing. to break up the monotony what I will often do is take a program/game I want to see work and execute until it hits an opcode I have not implemented, then implement that opcode and try again.

What is worse, is that it may take you two or three emulators or two or three re-writes of this emulator before you get the feel for how you could have saved a lot of typing and/or how you could have better designed re-used/logic. By trying to execute a favorite rom you get a randomish instruction mix that puts you into various parts of the opcode table and as you re-use code for those opcodes you might...might...be able to improve your design with less re-writes.

As R. is probably describing if you instead create a spreadsheet or some other software parsable table you can write and re-write a simulator code generator from that table. Here again you can start small you dont have to make a complete table, try a handful of different flavors of opcodes and see if you cant figure out a table format that allows your parser to generate code for the simulator. You can later add flags and other things and make the whole process grow as it improves. At the end of the day though, be it a table or actual code, you are eventually going to have to have typed in all of those opcodes.