On Tuesday, December 11, 2018 at 11:13 AM, Paul Koning wrote:
> > On Dec 11, 2018, at 1:40 PM, Mark Pizzolato <m...@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
_______________________________________________
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh
