[Simh] Potential design for 'real time' controls

[Kevin Brunt]

If you do a bit of 'systems analysis', it's clear that the SIMH 
'console' is being used for four different things.

a) system configuration
b) processor 'front panel' operations
c) system console (with processor running)
d) 'operator activities' (eg tape mounts)

Type a) activities correspond to physical installtion of hardware, 
which (prior to the advent of 'hot-swapping') is done with the system 
powered down.

Types b) and c) were separate, but became 'entangled' when ROM 
technology progressed to the point that the front panel could be 
replaced by a soft console running in the hardware bootstrap. SIMH's ^E 
corresponds directly to the use of ^P on a VAX-11/750 console.

Type d) is obviously separate. You don't mount a mag tape on the system 
console or the front panel!

What is needed is a separate control channel for 'operator' activities. 
The obvious way to do this is to use multiple threads and the telnet 
multiplexor.

Consider this scenario.

Establish an 'environment simulation' thread. This communicates with 
the 'outside' through a telnet connection, with its own command 
interpreter. [This last is not strictly necessary. I can envisage the 
use of the UNIX msgsnd/msgrcv IPC mechanism, with the 'command 
interpreter' being a separate command in another 'window'.]

The 'environment simulation' thread accepts commands for ATTACH and 
DETACH operations (and anything else appropriate,) and performs the 
underlying file opens, etc, asynchronously to the running processor 
simulation. Synchronisation between the two can be achieved by an 
'environment' device in the processor simulation, which polls for 
actions which need to be performed on device data structures.

This does not preclude the existence of ATTACH and DETACH commands in 
the SIMH console - they just need to integrate correctly. This wil 
probably mostly 'come out in the wash' with the correct organisation of 
the support routines.

Kevin Brunt
 
On Wed, 06 Apr 2005 17:15:14 +0000 bsupnik at comcast.net wrote:

> One of the more frequently requested features is the capability to 
> issue certain SIMH commands without stopping simulation, notably 
> ATTACH and DETACH.  This note outlines a potential design for 
> implementing this capability. 
> 
> The problems with 'real time' commands are several-fold: 
> 
> 1) There is no mechanism for collecting command input while the 
> simulator is running. 
> 2) There is no mechanism for rerouting simulator command output from 
> stdout. 
> 3) Many of the commands, and many of the VM-specific routines, will 
> cause significant malfunctions if executed while simulation is 
> running. 
> 
> The proposed mechanism for command input is an extension of the 
> current mechanism for diverting the console to a Telnet window.  If 
> the simulation console is a Telnet session, than the main command 
> window is more or less idle.  Keyboard input (except for ^E) is 
> ignored; and nothing should generate output to stdout. 
> 
> Accordingly, it would be possible to poll the main command window for 
> keyboard input and to interpret accumulated input (as delineated by 
> \r) as commands.  SCP would have to provide a polling routine to get 
> (and echo) keystrokes, as well as minimal local line editing 
> capability (like backspace/rubout and line erase). 
> 
> Because the polling would be done from a normal event subroutine, the 
> command poller would execute only between instructions.  This at 
> least prevents multi-threaded race conditions.  But there are 
> undoubtedly code sequences in SIMH that are safe for this 
> environment. 
> 
> Many commands are irrelevant or unsafe in an executing simulator: 
> 
> - RESTORE: destroys all state 
> - SAVE: takes too long in large memory configurations 
> - RUN, BOOT, STEP, GO, CONT: the simulator is already running 
> - RESET: resets all state in a device
> - EXIT: simulator should be stopped first 
> 
> Others are harmless: 
> 
> - ASSIGN, DEASSIGN 
> - EVAL
> - EXAMINE 
> - SHOW
> - HELP 
> - BREAK
> 
> While others may or may not work:
> 
> - ATTACH, DETACH
> - SET 
> - DO: would have to obey the same restrictions as a command line 
> 
> The proposed design would add a flag to command tables, a flag to 
> devices, and a flag to SET/SHOW options, indicating that they are 
> 'safe for realtime'.  Thus, a command would only be allowed by the 
> real time interpreter if it is, in general, safe.  Within 
> ATTACH/DETACH and SET, particular devices or options would only be 
> allowed if they are safe.  Thus, real-time capability could be added 
> device by device, and option by option, as the VM code is inspected. 
> 
> Note that VM routines can already tell whether the simulator is 
> running by examing variable sim_is_running.  Today, of course, none 
> of them bother. 
> 
> It may also pay to add a general REWIND command, which would reset 
> the position indicator of sequential devices to 0.  It's equally 
> possible that REWIND needs to be device specific, so that local 
> status bits are set correctly to reflect beginning of tape. 
> 
> /Bob