> There would be some hope that multi cores would somehow come to bear on
> helping the execution of the various machines... if the different emulators could
> be separated into processes that could migrate to other cores. I don't have any
> real experience here to know if that could be arranged. I hoping but intuitively I'm
> think the whole chain would be in one process without mods to the emulators, which
> would would be a big pain. Otherwise it would seem to me the layers of emulators
> would seem to have to interprocess communicate.
The focus is really on whether you can do this in multiple threads, not which cores they are running on. Unless you're simulating a multi-core machine to start with, I don't see how using threads would make this any easier except for possibly emulating hardware. Ie, your 6502 thread writes to a simulated I/O location that sends a byte to the serial port on the emulated target; the output to a window emulating a VT-100 might be a good candidate for another thread.
Simply splitting each simulated processor into a separate thread is counter-intuitive since the early microprocessors were all single core anyway. Ie, using multiple threads to run my 6502 emulator even faster works how? Every other 6502 instruction is executed by two different threads? Emulating a 2 MHz 8 bit processor on a 3 GHz 32 bit processor will run plenty fast without doing instructions in parallel. Each thread has to be synchronized so as not to run ahead of the other... it wouldn't work too well to do a conditional branch on one thread while another thread hasn't completed the previous compare instruction.
If you're running a Z80 simulator on a 6502 simulator on top of an 1802 simulator, where would you split the threads? Going multi-threaded works where you want to run many things in parallel, but I'm not seeing much advantage for this application since you're trying to emulate single-threaded systems.
Maybe I'm not understanding what you're trying to accomplish.
Bob - K2UT