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 _______________________________________________ Simh mailing list [email protected] http://mailman.trailing-edge.com/mailman/listinfo/simh
