You will need to be careful with the I/O window when using multiple threads. The simulated OS usually depends on the interrupt (or data) to be in the buffers/registers within a certain minimum/maximum I/O window.
It can be a lot harder to assure the I/O delivery within the I/O window using multiple threads, because of the non-guaranteed thread wake-up problem - unless you plan on burning multiple threads at 100% with spinlocks [which in essence is what independent I/O processers did]. The specified sleep/nanosleep() time is the minimum duration - there is no maximum duration, it depends on the host OS thread scheduler. As noted by Holger, SIMH makes managing the I/O window easier by allowing the simulated hardware device to schedule a same-thread callback after a certain number of CPU ticks, so that the I/O completion event can be precisely timed to hit between the minimum/maximum of the I/O window. A simpler threaded solution might be to create an I/O work packet, and drop the work packet into a thread pool for immediate execution, but still using the existing SIMH event callbacks to "complete" the I/O within the I/O window. The I/O worker thread will likely complete before the minimum I/O window, and then the SIMH event scheduler can delay the I/O completion until after the I/O minimum window occurs. If the worker thread hasn't completed the I/O by the time the SIMH event callback occurs, the callback can reschedule another completion event for a later time. However, note that a busy host may not even schedule the I/O worker thread until after the I/O window closes, which will cause a simulated device driver timeout - and there's really nothing that you can do about it, other than to "drop back" to a single threaded implementation. There are some thread portability considerations, yes - pthreads may be the most portable thread implementation at this point. But the biggest issue is still the accuracy of the simulation across all of the supported platforms. Dave -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Holger Veit Sent: Tuesday, April 05, 2011 8:01 AM To: [email protected] Subject: EXT :Re: [Simh] Multiple Processors Am 04.04.2011 23:53, schrieb Rob Jarratt: > Threads in SIMH would be great for emulating many devices too. I suspect the > reason they are not there and that it is polled is portability. I have never > looked into seeing if there is a way to get threads on all the supported > platforms, but if anyone else has then it would be interesting to hear about > it. > > Regards > > Rob >> On 04/04/11 5:10 PM, Bill Beech (NJ7P) wrote: >>> All, >>> >>> I am in the process of writing an emulator for the Intel 310 system. >>> I would like to know if anyone has figured a way to emulate multiple >>> processors in one emulation? The Intel 310 used the following >>> processors simultaneously: >>> >>> Master CPU 80286 >>> Serial Board Slave 80188 >>> Ethernet Slave 80188 >>> Tape Drive Slave 8089 >>> Hard Disk Slave 8089 >>> >>> Any thoughts? You don't need threading in simh, because it already implements sort of threads by implementing an event queue to process I/O events. Threads are just a light-weight word for "scheduling in a single executable". Simh is thus very similar to an operating system (as any simulator is, in principle). What you need for multiprocessors is splitting the sim_instr() function into independent handlers for each CPU. When done correctly, it will also allow multiple instances of the same CPU in a single simulator. Admittedly, doing this is much simpler with real OO concepts, where you just instantiate one or more CPU classes and then, in a loop call their "sim_instr" methods sucessively for a single CPU instruction and increment simulator time accordingly. Besides, many simulators have "intelligent" I/O gear; you should carefully analyze whether the tape and disk slave subsystems actually need to be emulated precisely, or just at their I/O border to the main CPU. See the Altair simulator in simh, for instance: the built-in floppy disk controller, including a DMA controller, might have been simulated precisely as if it were an independent machine, but actually, it is sufficient to pass it certain read/write/format/seek commands in special registers, and then, after some time passed, it will magically transfer data from an emulated disk file directly to the emulated main memory of the Altair machine, and throws a "command done" interrupt. -- Holger _______________________________________________ Simh mailing list [email protected] http://mailman.trailing-edge.com/mailman/listinfo/simh _______________________________________________ Simh mailing list [email protected] http://mailman.trailing-edge.com/mailman/listinfo/simh
