System/161 is a machine simulator. The virtual machine it simulates is a server-class computer, with a serial console, multiple CPUS, multiple disks, and one or more network interfaces. The formal processor clock speed is 25 MHz, the speed of a high-end server circa about 1990. This speed is a tradeoff between genuine processor speeds and the speed the simulator code can manage in real time, which is markedly lower.
The virtual machine is constructed in as simple a fashion as is reasonably possible while still maintaining most of the feel of real hardware. (The part of dealing with real hardware you miss out on is the part where the interfaces are screwy and the devices don't work half the time.)
The machine has 32 slots in a passive backplane bus called LAMEbus. One slot contains the system board with the LAMEbus bus controller. This board may contain up to 32 CPUs, each of which may potentially contain multiple cores. Each additional slot may be configured with any of several hardware devices. This configuration is established using a config file, named by default sys161.conf. Future versions of System/161 may provide a user interface for device configuration and/or allow devices to be inserted and removed on the fly ("hotplugged"), but this is not currently supported.
Programming information for LAMEbus
The system board contains up to 32 simulated 32-bit MIPS microprocessors. The MIPS is the simplest "real" 32-bit processor for which development tools are readily available; furthermore, the MIPS architecture is already widely used for teaching in various contexts. This makes it a natural choice.
Programming information for the System/161 MIPS processor
By default the config file is named sys161.conf and read from the current directory. An alternate file can be used by specifying the -c option. The syntax is line-oriented, with # comments. Each line specifies the contents of a slot, which may be between 0 and 31, and includes optional configuration arguments for the device to be inserted. The format of a configuration line is as follows:
slot-number device-name [args...]The system board (bus controller) must always be placed in slot 31.
| |||
System/161 maintains timings internally at a granularity of a single clock cycle; thus it can be used for very accurate profiling, to the extent that its execution time model is realistic.
The timings in System/161 have the following known limitations:
There is also the issue that System/161 cannot actually execute 25 million instructions a second, even on a fast machine. Therefore, on CPU-intensive tasks, it falls behind. In order to maintain the illusion that it continues to run at 25MHz, it distinguishes virtual time (within the simulation) from wall time (outside the simulation). All internal timings are calculated in virtual time.
Wall time is of interest, however, because the interactive behavior of the system occurs in wall time. For this reason, System/161 attempts to sync itself to wall time. For I/O-intensive tasks its interactive behavior is time-correct; for CPU-intensive tasks it is very slow. In the transition from one to the other some odd artifacts can occur; these can be made odder yet by scheduling interactions with the host OS if running on a busy system. These are most noticeable on the system console, but can also occur if one is using the virtual network.
For this reason, it's important to be cautious about evaluating software performance by eyeball; appearances can be quite misleading. Use the internal timers. If there's something you need to do that the internal timers can't support, please file a bug report.
Currently, when multiple CPUs are configured, they execute in lockstep in a single host-level thread, and the timing model is unchanged. It is likely in the future that it will become possible to run each virtual CPU on its own host-level thread; this will add major complications to the timing model, the full ramifications of which are not yet completely clear.