This one is for you cpu/assembly guys:
Ok I admit this if for a modified Z80 (*cough Gameboy *cough), which has like 300+ different operations, and over 8 useable registers. What I'm wondering is whether the way I set up the processor is a great balance between simplicity and speed. This could also work with an NES cpu:

What I have is two arrays, both 512 INTEGERS each. (Yeah that blows :|)
At any rate one is called the AddressingModes array and the Operations Array. They are filled with certain values at startup, and to execute an instruction the processor does thus:

Grab opcode from PC
jmp INDIRECTLY from the opcode's index in the AddressingModes array.

For instance

mov ecx, [PC]
jmp [ecx * 4 + AddressingModes];

The addressing modes has two flavors: Static and Moded. The moded addressing modes area will load an ADDRESS in eax. The static will load a VALUE in eax. So if I was doing the INC X function, where X is one of the registers, then I would jump into the mod addressing mode area, load the address for the register I want to increase, then jump into the operation area:

INC A would jump into the mod A area:

lea eax, A;
jmp [ecx * 4 + Operations];

NOW the operations array would hold locations for that particular opcodes operation area. For INC A it would jump into the INC X operation area:

inc [eax];
lahf; <- save the flags.
mov Flags, hf;
jmp @EndInstruction;

Then it is done. If an instruction, say LOAD A, B (which moves B into A) was executed, then I would jump into the static addressing mode area, load B into eax, then jump into the operation area for LOAD A, X - which would then simply copy whatever is in eax into A.

I just wanted to see what you buffs thought of this. This keeps the code small and simple, since operations are encoded only once. On the other hand, a function may have 3 jumps in one instruction, which is a lot of cycles. Only using one indirect jump into a HUGE list of operations (INC A, INC B, INC C, INC D...) is A LOT of code and most likely a lot of time would be lost there in moving data in and out of processor cache.

An NES cpu probably doesn't have enough instructions to warrant something like this, but the z80 has a monstrous amount - it even has extra ones by using two-byte opcodes. :|

Thanks in advance.

Not to be unhelpful or anything, but this is almost exactly how opcode tables and instructions were handled in qNES.

-- jdc

I don't know if that's a good thing or a bad thing. :)

>I just wanted to see what you buffs thought of this

Yeah, looks like you know what you're doing (BTW, I like what you're doing with LAHF- I've done this myself).


>This keeps the code small and simple, since operations are encoded only once.

Sounds like somthing I'll be doing with my clock-cycle based 6502 core :)


>On the other hand, a function may have 3 jumps in one instruction, which is a lot of cycles.

I think you're being to critical about how much time the x86 is going to spend on pipeline flushes. Remember, the slower the x86 CPU (generation-wise), the less overhead those jumps are going to take. Don't worry about it.


>Only using one indirect jump into a HUGE list of operations (INC A, INC B, INC C, INC D...) is A LOT of code and most likely a lot of time would be lost there in moving data in and out of processor cache.

I'd agree with that too. My best advice is to keep things simple. It makes debugging easy, and it also keeps your code simpler.