[Simh] vax idle for NetBSD

Mark Pizzolato Mark at infocomm.com
Tue Dec 11 12:08:32 EST 2018


On Tuesday, December 11, 2018 at 7:47 AM, Anders Magnusson wrote:
> Den 2018-12-11 kl. 11:11, skrev David Brownlee:
> > On Sun, 9 Dec 2018 at 09:42, Mark Pizzolato <Mark at infocomm.com> wrote:
> >> Well, when I followed the directions you pointed out, I did see what you
> >> had reported.  A little deeper observation strongly suggested that the
> >> OS execution flow that happens on NetBSD/VAX during idling had changed
> >> from how things were working when I had worked through how to get
> things
> >> well behaved idling under simh.
> >>
> >> I haven't yet had the time to look closely at the OS code to determine
> >> what exactly was happening.  If you're seeing things OK now, maybe, there
> >> is some sort of garbage collection activity going on, which runs for a while
> >> and then somehow eventually stabilizes to the known idle execution
> >> pattern.
> >>
> >> NetBSD is the fundamental exception for operating systems running under
> >> simh due to the fact that it is still an actively developed and evolving
> >> operating system.  As a result, the idle detection pattern will always have
> >> to evolve along with the evolving OS.
> > That also cuts both ways (but in a good way :) - because it is still
> > under active development it is reasonable to tweak the code to work
> > better under simh (other ports like amd64, aarch64 and mips are
> > adjusted all the time to work better under qemu), so if there is a
> > better way for NetBSD to tag the idle loop, lets make it so :)
> >
> > For anyone interested the current logic has:
> >
> >          int ipl = mfpr(PR_IPL);
> >          mtpr(1, PR_IPL);
> >          mtpr(ipl, PR_IPL);
> >
> > Which looks to have been there since 2012 - see
> > https://nxr.netbsd.org/xref/src/sys/arch/vax/include/cpu.h?r=1.102#162
> >
> Hm, the vax actually got a WAIT instruction in later versions of the
> hardware.
> It could be an idea to use it (and add code to catch it if not implemented).

Well, we could do that in the platform specific idle code, but it wouldn't change 
the extended delay in the OS that Paul and I originally observed before the idle 
code is actually engaged.

- Mark


More information about the Simh mailing list