On Thursday, January 18, 2018 at 9:27 AM, Lars Brinkoff wrote: > Thanks, that's good to know. It's encouraging that something is underway. > > Are the machines running inside the same process? I was vaguely thinking > about running machines as separate processes, with some communication > mechanism between them.
The goal is to leverage the existing simulator code without any heavy lifting which would be required to have multiple simulators running in the same process. > Maybe shared memory, maybe something else. What I'm working on is based around shared memory which may or may not be used directly by the device simulator using it. This allows the same interfaces to leverage the rest of the hooks into SCP. > It wouldn't even have to be SimH in both ends. In theory that might be true, but that won't be a primary goal. - Mark > > SimH knows nothing of the internal structure of simulators, so I'm > > skeptical of a SimH-level solution. However, a simulator-specific > > interface can be built. > > > > As an example, I am finishing up the UC15, which is exactly what you > > describe - a PDP11 that is connected to the memory of a PDP15 and > > controlled via a cross-connected paralllel link. The PDP11 acts as an > > IO processor for the PDP15. > > > > I have not solved all the problems. The solution requires a multi-core > > (or other kind of SMP) system, with one core per simulator. It > > probably depends on in-order writes and strong cache consistency > > semantics. And it definitely depends on tight polling, which causes > > the cores to run flat out (unsuitable for mobile devices). > _______________________________________________ > Simh mailing list > Simh@trailing-edge.com > http://mailman.trailing-edge.com/mailman/listinfo/simh _______________________________________________ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh