> I'm thinking mainly of ARM, MIPS portable machines here by the way - x86 of
> course for 68000 is done and dusted since Pentium 2s.
68K on a slow MIPS would suck. On ARM, it probably would, too, but I don't know how much because I don't know much about ARM's subtleties off the top of my head.
X86 is nice because of the almost 1:1 flag mapping. What about ARM? ARM can automatically shift operands and supports conditional execution -- would that help in flag calculation and/or on-the-fly instruction decoding?
I don't think anyone's even tried writing a hand-tuned 68K interpreter for ARM in assembly.
> like this:
> struct Opcode
> void (*execute)(int currentPc); // Handler for executing the opcode, either
> the flags version or not
> char ra,rb; // Registers to use
> And then you allocate a new one for each unique opcode (e.g. move d0,d2 gets a
> new Opcode structure, but following move d0,d2 opcodes point to the previous
Wouldn't that imply that you'd have to translate an instruction sequence into an array of pointers to Opcode structs? The idea you have, if I understand correctly, is that a lot of the same opcode structs would be used.
But this adds a level of indirection and might even increase memory usage (because, realistically, how often is the same instance of a single instruction used?)
> By the way... was there a name for this thing? It seems halfway between an
> interpreting emulator and a recompiler...
I think the term "threaded interpreter" still applies here. Or "pre-decoded interpreter", if you want -- that sounds descriptive.
>Generator calls it a Dynarec, but it
> doesn't quite seem to me that it is because it doesn't emit real code, only IL
It could generate real code to do the CALLs and parameter pushing if it wanted to.