> On Feb 22, 2018, at 3:09 AM, Chris Hanson via cctalk <email@example.com> > wrote: > > On Feb 21, 2018, at 11:09 AM, Al Kossow via cctalk <firstname.lastname@example.org> > wrote: >> >> That is tricky to cleanly and efficiently implement where each component is >> modeled independently and >> glued together with a higher-level framework. > > This is why I wonder if multithreaded emulation might be a reasonable future > approach: Model more components of a system as operating independently as > they produce and react to signals, have them block when not reacting (either > to a clock pulse or a signal), and let the operating system manage scheduling.
It depends on the machine being emulated. In some cases, multiple components that seem to be independent actually have tightly coupled timing, and software relies on that. For example, a CDC 6000 series mainframe has 10 or 20 PPUs plus one or two CPUs. With a bit of care, you can model the two CPUs using two threads. But all the PPUs have to be done in one thread because they run in lockstep. If you make them each a thread, the OS won't boot. I tried it and gave up. It would have been nice, it might have opened a path to a power-efficient emulation, but it didn't appear doable. Processors vs. I/O devices might work, but again the devil is in the details. paul