[Simh] vax idle for NetBSD

[Mark Pizzolato]

On Tuesday, December 11, 2018 at 11:13 AM, Paul Koning wrote:
> > On Dec 11, 2018, at 1:40 PM, Mark Pizzolato <Mark at infocomm.com> wrote:
> >
> > The simple test with the VAX simulator is to enable any OS form of
> > idling and boot the simulator.  While sitting at the ROM >>> prompt
> > idle kicks in precisely as expected.  Similarly, when booting VMS, idling also
> > occurs as expected.
> 
> I see it now on NetBSD, takes about 20 seconds from the time the OS goes idle
> (the login prompt).
> 
> Interesting that the boot prompt would idle, since that's not NetBSD...

There are a couple of non OS dependent behaviors which are innately idling.

These include:
  1) Any branch to self instruction with interrupts enabled (IPL != 31).
  2) Sitting at the hardware boot ROM prompt awaiting user input before 
      proceeding.
Similarly, a branch to self instruction with interrupts disabled (IPL == 31) is an 
infinite loop that will never exit, so simulation execution stops.

> Tried it on ELX8, I see roughly the same.  Tried "show -d idle" and it reports
> something plausible sounding:
> 
> idle enabled, stability wait = 20s, minimum sleep resolution = 1ms
> 
> I then continued, and noticed that the simulation goes CPU bound for 30
> seconds, then returns to idling.  Tried it again, same result.  Is that caused by
> the clock catching up?  Come to think of it, clock catchup is not all that useful
> for this system, is there a way to have the timekeeping be real simulation time
> only, so time at the SIMH prompt does not count?  The clock is used for
> scheduling etc. but not for timekeeping (not in any OS I have seen for that
> machine, anyway).

It is not clock catching up.  

The stability wait interval occurs each time instruction execution starts (i.e. 
proceeding from a sim> prompt with RUN/CONTINUE/GO, etc.).  This is likely
what you're seeing.

A relatively recent change was added to avoid restarting the stability wait 
period if execution is resumed before the elapsed wall clock time would have 
caused another clock tick to have been generated.  This was to support good 
behavior when execution exited due to some EXPECT condition matching 
with EXPECT actions that resume execution very quickly.

- Mark