> On Feb 22, 2018, at 3:09 AM, Chris Hanson via cctalk <cctalk@classiccmp.org> 
> wrote:
> On Feb 21, 2018, at 11:09 AM, Al Kossow via cctalk <cctalk@classiccmp.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.


Reply via email to