[Simh] Multiple Processors

[Bill Beech (NJ7P)]

All,

Very good discussion.  I will look at MESS.

I think Holger hit the nail on the head.  I can emulate functionality at 
the multibus interface and use the SIMH queue to do the work much as the 
AltairZ80 did at the S-100 interface.  Threads would possibly break the 
portability of SIMH and I don't want to do that.

Back to think on this problem while I get the 8088/8086/8188/80186/80286 
processor emulation completed and validated.

Bill

On 04/05/2011 05:00 AM, Holger Veit wrote:
> 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.
>