[Simh] PDP-11 RESET instruction disables ^E

[Mark Pizzolato - Info Comm]

On Friday, April 13, 2012 at 6:55 AM, Bob Supnik wrote:
> A similar problem exists in the PDP8, PDP18B, and potentially the VAX.
> 
> The problem is a side effect of an attempted optimization around
> idling.  Idling will sleep the CPU only if the queue of IO events has
> no IO events scheduled for a period of time at least as long as the
> minimum sleep interval (typically 1msec these days).  This sleep
> interval has to be calibrated against real-world time; otherwise, the
> real-time clock will get out of sync with wall time.
> 
> As hosts have become faster, the keyboard activity probe (which was set
> at 5000 cycles back in the 90s) has become too short, and as a result,
> the CPU would never choose to idle.  The idle probe interval could be
> set to a larger value, but a "better" solution is to calibrate it to
> the real-time clock, and probe when the clock ticks (typically, 50 to
> 100 times per second). If the terminal multiplexor probes are also
> synchronized, then the simulator will handle all these events at the
> same time, and the event queue will tend to have more "sleepable"
> intervals.
> 
> While the keyboard probe is scheduled from simulator start, in some
> systems the clock and the terminal multiplexor probes can get turned on
> or off by software.  Accordingly, the keyboard probe was scheduled with
> sim_activate_abs, which sets the probe time to an absolute time in the
> future.  The default, sim_activate, will not change the scheduled time
> if the event is already scheduled.
> 
> So the short-term answer is to revert all the keyboard scheduling from
> sim_activate_abs to sim_activate, recognizing that these clock-
> calibrated events can drift out of sync and thus reduce the efficiency
> of idling, or even make it not work altogether.

Looking at pdp11_stddev.c, you mean to change sim_activate_abs to sim_activate in the tti_reset and possibly the tto_reset routines?  

That would work AND if the tti_svc (and tto_svc) did a:
     sim_activate (uptr, clk_cosched(KBD_WAIT (uptr->wait, tmr_poll)));   /* continue poll */
instead of the current:
     sim_activate (uptr, KBD_WAIT (uptr->wait, tmr_poll));   /* continue poll */
The polls would be aligned for idling.

In the degenerate case which started this discussion, there would be a TON of keyboard polls, but we're not really worried about that case.  The normal cases would work correctly no?

> Long-term, it might make sense to segregate events that are scheduled
> off the instruction counter from events that are scheduled against
> real-time, either inside a simulator or at the SCP level. But that's a
> discussion for another day.

Agreed.

- Mark