[Simh] Questions regarding future simulator development

[Timothe Litt]

On 11-Apr-13 09:59, 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.
Yes, this is what I had in mind.  Single-threaded actually helps.

I don't see why the Telnet window is required to make this work. Running 
from a terminal window should work the same way.  Probably can be done 
with some slight of hand in sim_console (sim_poll_kbd/sim_os_poll_kbd); 
but I haven't really looked at the code in a long time.

Also, if acting on ENTER is done at 'next instruction' time, there 
should be less breakage.  DEPOSIT should work about as well as console 
switches on real hardware.  (Useful for deposit 30 -1 (crash 
TOPS-10/20), VAX SIRR for quorum/XDELTA, etc).  But there probably will 
be some breakage where timed device events don't check for 'still 
attached' and need to set some error bits.  It's not obvious why (given 
that command execution is synchronous) these wouldn't be bugs in the 
current code.  Certainly more likely to be exercised.

The hook looks something like this:

There are 4 states for keyboard input (char ready):
     (0) "not simulating": cooked, current command table. 
"BOOT,CONTINUE,START" S-> "simulating"
     (1) "simulating" raw: look for ^E (print prompt S-> "^E received") 
- other chars to console device
     (2) "^E received": buffer input to ENTER; ENTER S-> "Enter pending"
     (3) "ENTER pending": wait for instruction boundary; execute 
restricted comand table;
           STOP S-> "not simulating";  other cmd S-> "simulating"

It might be good to check for ^E as the first character in (2), so ^E^E 
can send ^E to the simulated console.

I hope someone has the enthusiasm and time to give it a whirl.

This communication may not represent my employer's views,
if any, on the matters discussed.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5159 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20130411/4ebeb7df/attachment-0002.bin>