On Wed, Feb 21, 2018 at 8:52 AM, Ray Arachelian via cctalk < cctalk@classiccmp.org> wrote:
> Now, you don't want to run your emulated guest CPU(s) at full speed on > the host machine, because you'll overheat it, and typically, it'll run a > multi-process OS anyway and you don't want to starve the GUI, network > stack, and daemons of CPU cycles, so once you reach your goal MHz in > your guest CPU, you'd sleep and yield to the host OS for a bit, or maybe > do some background stuff like see if any I/Os or IRQs are pending (such > as maybe a keystroke from the user, or an incoming network packet, or > maybe the disk sector or tape sector your guest OS requested has > arrived), and handle those. > > For the case of Multics on the DPS8/M, the idle loop is implemented with the "DIS" instruction -- Delay until Interrupt -- which stalls the DPS8/M CPU until an interrupt or the Timer Register runs out. The Timer Register is set for 1/4 second. The emulator implements the DIS instruction by sleeping for 10 milliseconds, checking for I/O events, decrementing the Timer Register by 10 ms and checking for runout, otherwise repeat. The host CPU shows <1% usage for a idling Multics system. This configuration was arrived at through an iterative process of understanding how Multics uses the Timer Register and trying to figure out how to implement a 512KHz countdown register in software without excessive overhead. Writing an good emulation can require more then understanding the hardware -- the way the software uses the hardware can help make design decisions. Because Multics only uses the Timer Register for process scheduling, and the quantum is always 1/4 second, having a low-resolution timer was perfectly acceptable and easily implementable. -- Charles
