Matthias Buelow <mkb@mukappabeta.de> writes:
> Concerning the proposals of recognizing an idle loop...
> I highly doubt to be able to unambiguously detect a
> sequence of instructions which in the kernel implements
> an idle loop...

Why not?  It's been done in other simulators, for other
operating systems, and on other processors.

> what if the same kind of instructions
> happens to be coded in an application program or somewhere
> else?

If the application enters a loop that does nothing until it
gets preempted, there's nothing wrong with the simulator
sleeping for that too.  In fact, it's a win.

> A dedicated microcoded "illegal" op, i.e., which
> is then trapped and implemented in microcode would probably
> be a lot more towards correctness than heuristically guessing
> something in some code seemingly specific sequence...

No heuristic needed.  The simulator can identify the exact
sequence used.

A heuristic could be desirable if one wanted to use the same code
to catch several variants of the idle loop in different versions
of an OS, or in different OSes, but that is by no means necessary.
It's just as plausible to let the user configure what idle loop
to watch for.

If putting a trap in the idle loop makes sense for some other reason,
I wouldn't oppose it.  But then I'd still want the simulator to sleep
in the actual idle loop that the trap handler reaches.  Perhaps other
people may not share my sensibilities, but I want the simulator to
simulate a VAX, not a kludge.

Of course, what gets put into the official SIMH release is Bob Supnik's
decision, not mine.  I don't presume to speak for him, but given that
his stated objective is simulation accuracy over performance, I suspect
that he would be more inclined to add code that detects the idle
loop.