> > > It's a good approach, especially when you don't have to keep re-fetching
> > > (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 assume that by fetching, you really mean decoding.
Both. If it's in RAM, you have to keep track of whether it's been overwritten, which can introduce significant overhead.
These sort of interpreters are essentially what's known as a "threaded interpreter." They have some of the same drawbacks as a dynarec.
> > > I don't know if it would be worth it for emulating a 68K on X86, though.
> > > calculation is simple (LAHF, SETO AL), and decoding can be pretty optimal,
> > > A68K shows.
> The only problem is that works only if you program the instruction handlers in
> assembly and its only going to work if you have native flags and flag extraction
Right, that's exactly what I was saying. If it's possible to do it good and fast in assembly, and you don't care too much about portability, go for it!
> For an interpreter, I would use an all-or-nothing approach. Do the flag
> analysis and select between handlers which calculate all flags and which
> calculate no flags. This significantly reduces the number of handler routines
> you will have to generate.
Agreed. But there may be a handful of instructions that often require a particular flag to be calculated, so it might be beneficial to occasionally generate that one extra handler.
> This is how the Nuon Aries3 processor works.
Speaking of which, is there a programmer's manual for this processor? I'd love to add it to my little collection of CPU/DSP documentation :)