> I'm wondering if (because C makes quite a good job on the register copies but a
> bad job on the flag calculation) dead flag analysis could bring C emulators very
> close to Asm ones and possibly even past them!
You could always write a better emulator in assembly which uses the same trick.
What's nice about this approach is that you don't have to worry about instruction decoding anymore. This can normally take a considerable amount of time and memory. If you look at the fast assembly 68K emulators, they generate many different permutations of each instruction simply to avoid having to extract register fields.
Starscream and Turbo68K had mostly the same approach and generated a lot of instructions. A68K is faster and I think that's mostly due to the fact that it generates much less code.
I'm not sure exactly what Generator does, but you can easily generate different permutations for instructions based on flags and then have a fetch/decode stage which outputs code like this:
... etc. ...
Or, to make it truly portable, have an array of structs of a type like this:
void (*Handler)(struct instruction *);
UINT32 field1, field2, field3, etc. ;
And simply iterate through this. I think this is what ElSemi was talking about (correct me if I'm wrong.)
It's a good approach, especially when you don't have to keep re-fetching code (if it's mostly in ROM, for instance, or in protected non-writeable memory pages) and you want to avoid having to write a full-blown dynarec.
I don't know if it would be worth it for emulating a 68K on X86, though. Flag calculation is simple (LAHF, SETO AL), and decoding can be pretty optimal, as A68K shows.
It's probably great for something like ARM or a low-end MIPS or PPC.