[Simh] EXT :Re: Multiple Processors

[Hittner, David T (IS)]

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: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing-edge.com] On Behalf Of Holger Veit
Sent: Tuesday, April 05, 2011 8:01 AM
To: simh at trailing-edge.com
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
Simh at trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh