21 Feb
2018
21 Feb
'18
1:12 p.m.
On Wed, Feb 21, 2018 at 8:52 AM, Ray Arachelian via cctalk <
cctalk at 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