Unless I misread Mark's message about the RQDX3 analogy, he is suggesting to put PDP-15 and PDP-11 in the same SIMH thread and in the same address space. When PDP-11 side becomes non-idle, it can signal an event and become eligible for execution, in a way similar to RQDX3. The options for co-execution with PDP-15 side in this structure are:
1) Execute PDP-11 exclusively until it enters idle state, then resume PDP-15 execution until PDP-11 becomes non-idle again.(This directly mirrors RQDX3 analogy). 2) Probably a better option (albeit dissimilar with RQDX3): co-execute PDP-11 and PDP-15 instruction streams on the same SIMH thread. I.e. execute of chunk of N instructions on PDP-15 side, then execute N (or M) instructions on PDP-11 side, then come back to PDP-15 main loop etc., and repeat this alternating execution of per-CPU main loops until one of the sides becomes idle, at which point the other side receives 100% share unless it becomes idle too. One disadvantage of this approach is namespace conflicts. But perhaps this can be addressed by restructuring SIMH build into machine-independent part and machine-specific parts, with machine-specific parts going to respective machine-specific DLLs/DSOs, with names local to specific CPUs not exported from these DLLs/DSOs and thus not colliding. A complication might be that while machine-independent part code may be shared, but some machine-independent data perhaps might be not (for instance the event queue may have the same logical structure for both sides, but either a separate instance of this structure is needed for each side, or resets etc. need to be handled in a more delicate and involved way taking into account which side is resetting -- so the required reorg may be deeper than at the first glance). The other disadvantage is that it does not leverage host multi-CPU resources. That's assuming computational performance matters at all. Yet the other disadvantage is the issues with calibrating VCPU speed. As the calibration now becomes significantly distorted by the co-executing CPU(s) going in and out of idle state in a rapidly varying pattern. Yet another disadvantage is that by default the consoles of two systems get mapped to the same host window, rather than being split, as they probably were in real life. Yet another disadvantage is a complication of the codebase to implement the mentioned reorgs or offset for them. The advantage is that it takes inter-thread synchronization issues out, includingmemory coherence issues and timing issues. But those may be not that great after all. ----- Original Message ----- From: Christian Gauger-Cosgrove <captainkirk...@gmail.com> To: Mark Pizzolato - Info Comm <m...@infocomm.com> Cc: "simh@trailing-edge.com" <simh@trailing-edge.com> Sent: Tuesday, March 17, 2015 6:58 PM Subject: Re: [Simh] Simulating the PDP-15/76 Unichannel On 17 March 2015 at 21:41, Mark Pizzolato - Info Comm <m...@infocomm.com> wrote: > Wasn't the RQDX3's processor a member of the PDP11 family? We don't try to > execute the RQDX3 firmware, but we merely have a device simulator that > communicates across the bus just as the RQDX3 did. Would an approach make > sense that implemented the PIREX behaviors in a DR15 simulation (possibly, > internally talking to the various UNIBUS device simulations)? > > Just a wild idea... > I mentioned that back on the GitHub discussion (just to plug it again: <https://github.com/simh/simh/issues/96>). The PDP-11 side of things does more than just run PIREX and respond to requests. The PDP-11 also runs the SPOL11 spooler package, and you can run custom MACRO-11 programs on the '11 loaded and started by the '15. Really the best way is to find some way of making the simulators talk to each other. Plus, that framework can be expanded towards other examples. (KL10 and PDP-11/74, being the ones off the top of my head.) Regards, Christian -- Christian M. Gauger-Cosgrove STCKON08DS0 Contact information available upon request. _______________________________________________ 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
