[Simh] No recognizable idle loop

Mark Pizzolato mark at infocomm.com
Tue Apr 4 03:59:58 EDT 2006



--- bsupnik at comcast.net wrote:

> I've seen this question so many times, here's the definitive
> answer: there is no idle job or simple idle loop in VMS.  Instead,
> VMS loops in the scheduler (at IPL 3) waiting for interrupts or for
> something to appear on a scheduler queue as a result of a higher
> priority interrupt.  Here is the code from VMS 7.2:
> 
> 61$:
> JSB	G^EXE$PROC_IDLE		;SEE IF WE HAVE  CPU SPECIFIC IDLE LOOP
> BLBS	R0,61$			;NO - GO TO STANDARD LOOP
> BBC	#CPB$V_RUN,CPU$L_CAPABILITY(R3),70$ ; RUN CAPABILITY PRESENT?
> BBS	R1,G^SCH$GL_IDLE_CPUS,60$ ;LOOP UNTIL WE AREN'T IDLE
> BRB	65$
> 61$:
> BBC	#CPB$V_RUN,CPU$L_CAPABILITY(R3),80$ ; RUN CAPABILITY PRESENT?
> TSTL	G^SCH$GL_TBSH		; Class scheduler present?
> BEQL	64$			; No, see if still idle
> JSB	G^SCH$CLASS_IDLE	; Yes, see if TBS job runnable
> 64$:
> BBS	R1,G^SCH$GL_IDLE_CPUS,61$ ;LOOP UNTIL WE AREN'T IDLE
> 
> This varies from release to release as well.

... there looks to be a typo in the above since the label 61$ appears
twice, the first probably should be 60$.

The above code IS the idle loop. As it turns out, BBS taking the
branch at IPL3 on the Interrupt stack only happens in the recent
versions of VMS in the idle loop.   No other OSes use IPL3 at all. 
The system will be spinning here until something fires due to an SCP
event updates some data that will let the loop exit.  I've had a
completely working simulator which I believe properly addresses idle
behaviors and doesn't soak the host cpu for several years now.  It
works with different detection code for the following cases:

  1 - VMS - Old versions
            this was the old BRB point at self pre SMP VMS (prior to
5.0)
  2 - VMS - recent versions
  3 - Console input wait loops
  4 - Ultrix - Whatever version I had to test with
  5 - BSD Unix (NetBSD, Quasijarus)

To get reasonable idle behavior, scp needs a little support to go
into an idle state, and slightly extended timing semantics to attempt
to keep the guest clock ticks and the rest of the event queue
processed in reasonably consistent way.

My implemention makes idle behavior an option in the case that
someone likes to soak up his host CPU cycles, or writes a new OS
which happens to catch one of the above idle detection conditions
inappropriately. (or merely wants to compare the simulated and host
system behavior with idle detection enabled).

None of the above indicated idle cases currently seem to interfere
with each other, however if someone felt they did, they could each be
enabled separately - adding complexity to the management side.

I'll be glad to try and merge this into a current simh version if
requested by Bob.  I've had this running on Windows, Linux and
Solaris on Sparc and X86.

- Mark Pizzolato

> /Bob Supnik
> 
> > 
> > Message: 5
> > Date: Mon, 03 Apr 2006 08:55:43 -0600
> > From: Villy Madsen <Villy.Madsen at shaw.ca>
> > Subject: [Simh] VMS Idle loop
> > To: simh at trailing-edge.com
> > Message-ID: <69d691969d7ad0.69d7ad069d6919 at shaw.ca>
> > Content-Type: text/plain; charset=us-ascii
> > 
> > Does anyone have a clue what the vax/vms idle loop looks like..
> > 
> > at one point in time I had been told it was just a
> > BRB pointing to itself
> > 
> > (so would that be brb 0 or brb -1 - it's been too many years and
> and I can't 
> > remember).
> > 
> > 
> > In case you are wondering, I am wondering if it would be possible
> to build a 
> > throttle into the simulator so that it doesn' run wide open all
> of the time...
> > 
> > Villy
> > 
> > 
> > 
> > ------------------------------
> > 
> > _______________________________________________
> > Simh mailing list
> > Simh at trailing-edge.com
> > http://mailman.trailing-edge.com/mailman/listinfo/simh
> > 
> > 
> > End of Simh Digest, Vol 29, Issue 2
> > ***********************************
> 
> 
> _______________________________________________
> Simh mailing list
> Simh at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
> 
> 




More information about the Simh mailing list