Writing emulators [Was: Re: VCF PNW 2018: Pictures!]

Charles Anthony charles.unix.pro at gmail.com
Wed Feb 21 15:12:11 CST 2018


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


More information about the cctech mailing list