Den 2018-12-11 kl. 11:11, skrev David Brownlee:
On Sun, 9 Dec 2018 at 09:42, Mark Pizzolato <m...@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).
-- R
_______________________________________________
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh
