> 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
> one)

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
> code.

It could generate real code to do the CALLs and parameter pushing if it wanted to.


----
Bart