[Simh] Questions regarding future simulator development (parallel control console)

[Michael Mondy]

On Thu, Apr 11, 2013 at 01:59:40PM +0000, Bob Supnik wrote:
[ ... ]
> 
> 3. The problem with "console while simulating" is that SimH (at least when I was developing it) is single -threaded. That said, there is a way to handle this within the existing framework:
> 
> - Insist that the console always runs via a Telnet window.
> - Let the keyboard sampling "device" look for more than ^E; in fact, let it accumulate type-ins into a command buffer. Note that all editing (echo, delete, etc) would have to be explicitly emulated, because the keyboard window, at that point, is in raw mode.
> - When ENTER is recognized, see if the command verb is part of a small acceptable set of commands that are safe to run while the simulator is executing. As Tim Litt points out, ATTACH and DETACH should work, because this is no different, from the simulator's point of view, than ^E, attach/detach, CONTINUE. EXAMINE is probably safe. Not much else is.
> 
> While it all sounds good in theory, I expect a whole bunch of things are going to break. Most notably, lots of SimH device service routines assume that if a device is attached at the start of the routine, it will be throughout and don't implement comprehensive error recovery further down.
> 
> [ ... ]

I think I see a way of supporting command console concurrency with
minimal change to the SimH architecture.  However, I don't think
I understand why such a thing might be needed.

The current model is that there is a set of core SimH routines used by
all simulators and per-simulator code to implement the specifics of any
particular hardware.

The SimH main() routine runs a loop calling the simulator provided
sim_instr() routine.  The sim_instr() can run for as long as it wants
and simulate millions of instructions if it so desires.  However,
sim_instr() is expected to monitor the sim_interval global, the
sim_brk_summ global, and the current value from sim_qcount() value.
Among other things, these mechanisms let the simulator know when
the SimH core code wants to take over.

I've been working on a simulator on and off since 2008.  It's only
partially complete.  I have a longer description of the interaction
between SimH and simulator code on my project wiki at:
https://github.com/MichaelMondy/multics-emul/wiki/FirstSeconds.
The documentation at trailing-edge goes into even more detail.

Adding concurrency seems feasible.   I could see a control console
thread that monitored for user input.  When the user wanted to perform
any action, the control thread could use the sim_interval global to
cause the hardware simulator to pause for a tiny fraction of a second
and drop back to the main() SimH code so that SimH could perform the
requested action.

In this way, the action occurs between two simulated instructions and
with the simulator in a stable state.  From the simulator's point of
view, it's no different than what happens today.  It's not running in
parallel completely independently, but for most actions, it would
probably be less than a microsecond of interruption.  Note that we
usually need some sort of synchronization/rendezvous point around
so-called "critical" sections of code in most parallel projects anyway.
In my simulator, I have a few hidden variable and data structures
that aren't visible to SimH.  I marshal them to/from the SimH
visible variables when entering/leaving sim_instr().  If the SimH
control console ran in parallel (without the rendezvous described
above), this approach would not work.

Similar approaches for parallel control might make sense for a GUI.

All that said, as noted in section 3.8 of the User Guide, typing
an interrupt character (^E) on the control console should cause
the simulator to gracefully drop back to the SimH command prompt.
Also, I think that on UNIX-like OSes, SimH allows a terminate signal
to cause SimH to drop back to the control console.

Thus, I don't see an urgent need for another mechanism to regain
control.  And, if simulators are allowed any private state, a parallel
control mechanism would have to pause/unpause the simulator anyway.

-- Mike Mondy