Simulation of operating systems

Eugenio Jacobo Hernandez Valdelamar

Arturo Rosenblueth Foundation. Insurgentes South 670-3. Valley Colony.

CP 03100. Mexico City, Mexico.
[email protected], [email protected]

Summary. This paper presents the main concepts of operating system simulation and
presents the development of a minimal operating system simulator as a case study.

Keywords: operating systems, simulation.

1. Simulation of operating systems

Simulation is an unobtrusive scientific method of study that involves experiments with

a model rather than the portion of reality that the model represents. Although much of the
information provided by simulation is already contained in the model, simulation is
useful when a large number of parts interact with many paths that need to be tracked
simultaneously, requiring a large number of iterations to approximate the results. The
ability to generate a synthetic history of dynamic processes and to manipulate the events
and conditions of the model is what makes simulation an ideal technique for the design of
operating systems, as will be seen later. Although a real implementation is considered the
only way to verify the effectiveness of a design, in the case of operating systems,
simulation has been applied by several working groups. Even though Silberschatz
mentions in his third edition of “Operating Systems Concepts” (pp. 126) that
"simulations can be very expensive, requiring hours of computing time, especially when
great detail is desired," it is clear that with the power of today's computers, and what is to
come, resource considerations can take a backseat.

2. Operating system simulators

Among the main operating system simulators are [1][2][3][4][5]:

a. NachOS (Berkeley). Nachos is an instructional system for teaching operating

systems courses. The Nachos distribution contains the base code for a working OS and a
generic computer simulator.

b. SimOS. It simulates computer hardware in sufficient detail to load and run

commercial operating systems, and provides a complete execution and workload analysis
environment.

c. RCOS. It is designed to help people understand the inner workings of an

operating system. RCOS is a multitasking operating system running on simulated
hardware, which is based on the P-Machine, a hypothetical simple computing system. It
includes a C/C++ compiler that generates P-Code that can be executed by the P machine.

d. SOS (Simple Operating System Simulator). The book "Operating Systems: A

Design-Oriented Approach" (Charles Crowley, Irwin, 1997) contains the code (C++) for
a simple operating system called SOS, which runs on a hardware platform called CRA-1,
which is a simple RISC machine.

e. Flux OSKit (Utah). It is a platform with a set of 34 component libraries that

facilitates the creation of a new operating system by porting an existing OS to another
platform (e.g. x86), extending device support, file system formats, executable formats, or
network services; as well as building related programs, such as loaders or servers
mounted on a microkernel.

f. Palm OS Simulator. It is the Palm OS 5.0 simulator; it is not a hardware emulation

like the PalmOS Emulator, but the real operating system running on top of a DAL
(Device Abstraction Layer). It is used more as a tool to validate possible errors and
compatibility of applications on PDA devices that have this version of the system.
It can be said that the objectives of operating system simulation are:
g. understand the inner workings of an OS
h. Determination of OS workloads on a specific processor (SimOS)
i. design of new operating system architectures
j. operating system migration
k. component-based development of operating systems, so that new kernels,
servers, drivers, loaders, etc. can be tested.

3. Simulation of a minimal operating system

It was decided to try to code a simulator that would do the simpler things that an
operating system (OS) is supposed to do. The first question that arose was: should we
model only the OS, or is it also necessary to model the hardware on which it runs? This
first problem is not as simple as one might suppose. Modeling a computer is a fairly
complex exercise; and as we have seen so far, an OS is also a fairly complex system, as
to increase the complexity of the implementation. However, there are some facts that
cannot be ignored:
- The operating system is created to manage the resources of a computer;
- The OS in most cases is highly dependent on the hardware, because although
high-level abstractions are created to model its services, the base levels are still
responsible for access to and control of the hardware;
- The OS, no matter how portable it is, needs to perform basic functions for its
 initialization and configuration, which are dependent on the computer's
resources and architecture.
This makes it clear that it is necessary to model the hardware to have a complete
simulation [5].

3.1 The hardware: URM

Thus, it was decided to return to a computer model called URM (Unlimited Register
Machine). Since this model is an abstract processor, and has very few instructions, it is an
example of controllable dimensions (having chosen a microprocessor such as a Pentium
or a PowerPC would be the subject of another work). The URM has an infinite number of
registers (R1,R2,R3...) each of which contains a natural number at all times. The contents
of the records may be altered by the URM in response to certain instructions that it may
recognize. These instructions correspond to simple operations used to perform
calculations with numbers. A finite list of instructions constitutes a program. The
instructions are as follows:
• Z(n). Zero instruction. Changes the contents of the Rn register to zero, leaving no
alteration to other records.
• S(n). Successor instruction. Increases the value of the number contained in Rn by 1,
leaving the other records unchanged.
• T(m,n). Transfer instruction. Replace the contents of the Rn register with the
value contained in Rm.
• J(m,n,q). Jump instruction. The contents of the Rm and Rn registers are
compared; if rm=rn the URM proceeds to the q-th instruction of the executing
program; if rm<>rn the URM proceeds to the next instruction.
In the original implementation of the URM machine simulator, the idea was to give the
machine a program written with the model's instructions, and have it execute them.
Revisiting this simulator to simulate a minimal operating system (SOM) requires new
considerations and several changes. The main consideration should be to separate the
hardware and software components of the model. Also in the original implementation:
• The loading of the programs was done by the simulator, and there was no explicit
program loader in the model.
The URM did not have any additional hardware (peripherals); only the processing
unit, its registers and the program memory.
If the URM is considered a processor, it is possible to use it under the Von Neumann
model, and thus model the hardware of a computer that uses it. Therefore, the minimal
system would require a processor, its registers and main memory. The model instructions
and their implementation would make up the processor's instruction set, and we can
afford to implement a small ALU for arithmetic operations. Additionally, part of the
operation of the Von Neuman model can be included by adding a fetch cycle and an
execution cycle to the machine's instruction cycle. These inclusions require adding two
special registers to the original model for these purposes. The instruction register (IR)
and the program counter (PC).
The URM incorporates an unlimited number of registers into its operation, but in real
processors, these registers are limited (accumulators, segment registers, stack registers,
code registers, etc.) so this functionality must be respected, although adjusting it to a
variable and finite number of registers, which will allow the configuration of the model
to be varied. As for memory, it can be modeled as an array, where each memory cell can
contain an instruction and its parameters. Therefore, memory access is linear, where the
array index is equivalent to a memory address (cell). This access involves reading and
writing data in memory. Although they are not explicitly part of the model, a couple of
instructions will be required to be implemented for these purposes (e.g. READ/WRITE,
GET/SET, IN/out, LOAD ax,dir/LOAD dir,ax, etc.)

3.2 The software: SOM

As far as software, specifically the operating system of this machine, is concerned, there
are two alternatives: either encoding the operating system in the simulated model code or
creating a module that takes care of the operating system's own functions. As mentioned
at the beginning, what is wanted is a minimal operating system, but... what is that?
Specifically, it is a piece of software that allows a program to be loaded into the model's
memory and executed by the processor. If we were to take the first option, the first thing
that jumps out is that since the model only consists of 4 instructions, the instruction set
would have to be extended to allow disk access, control devices, display results on an
output device, etc. Although this can be done, the model would become a new processor,
and in that case it would be better to emulate a processor with enough instructions to
implement a complete OS. The second approach is equally valid, since if the same
simulator implements the modeling of the functions of our minimal OS, the result of the
simulation is the same. This option is the one that has been implemented. Making this
decision involves some extra considerations, such as:
• That the program loading address will be the start of the array that is used. This
would be interpreted as the OS being already loaded into memory, and that area
being protected from access by other programs.

That the OS implements device access functions, even if these are not explicitly part
of the model. Standard input/output is equivalent to the simulator having a monitor.
In this way the SOM would have all the characteristics of a resident monitor, one of the
first OSs, which can be extended to implement batch processing, for which a JCL (Job
Control Language) must be included. The model will only run one program at a time, so
process management was not implemented. Furthermore, with the simplification of
memory access, a memory manager is not needed, although it could be useful if you
wanted to expand the base memory of the model. The SOM is composed of the classes
(fig. 1):
• Loader, is responsible for loading programs from their files into memory for
execution.
• JCLInterpreter, is responsible for interpreting JCL commands.
• Monitor is composed of Loader and JCLInterpreter and is responsible for loading a
program or a set of programs into memory and then executing them, based on a
sequence of JCL commands.
 Fig. 1. SOM simulation class design

4. Results

The strategy for building the simulation model consisted of modeling the main
administration services of the operating systems (processes, memory and devices), and
then integrating them in different configurations, hoping that the integration task would
bring up problems and considerations that would provide interesting solutions and
experiences for understanding the design and implementation of the simulator. Although
at the beginning it was planned to only encode the algorithms and modules that are
important for systems based on modular cores (the most widespread currently), the
simulation of each of these parts, and of the hardware related to their operation, has
resulted in some configurations similar to the first systems (simple but very illustrative).
The main results of this first experiment are:
1. Choosing the URM model for simulation does not allow experimenting with
programs that have full control over resources. To this end, the instruction set should
be as real as possible, although for the purposes of this paper, it should have as few
elements as possible.
2. The URM instruction set is sufficient to create useful programs, however, additional
instructions would have to be added for register control, memory and resource
access, etc.; that is why real processor instruction sets have so many instructions.
3. Implementing I/O device abstraction reduces complexity, since modeling specific
devices, such as network cards, etc. requires more theoretical and practical elements.
4. To strengthen the simulation model, it is advisable (if not essential) to allow the user
of the tool to view the behavior of the model, and even modify its behavior, at any
time.
5. Conclusions

The simulation approach has already been used in 2 operating systems courses at the
Arturo Rosenblueth Foundation with very good results, since the students have had the
opportunity to explore the interior of this type of systems, and from there, they
themselves have made their own simulators. Furthermore, this approach allows
developers to test new OS subsystems before a full implementation, which reduces costs
considerably.

References

[1] RCOS: Yet Another Teaching Operating System. Ron Chernich, Bruce Jamieson, David
Jones. Proceedings of the First Australasian Conference on Computer Science Education.
http://webfuse.cqu.edu.au/Information/Resources/Readings/RCOS.java/yato/
[2] The Design and Construction of a Simulated Operating System. Ron Chernich, David Jones.
Asia Pacific Information Technology in Education Conference, Brisbane, July 1994.
http://webfuse.cqu.edu.au/Information/Resources/Readings/RCOS.java/Design/
[3] Not just another teaching operating system
http://webfuse.cqu.edu.au/Information/Resources/Readings/RCOS.java/njato/
[4] Modern Operating Systems Simulators. http://www.ontko.com/moss/
[5] Design and simulation of operating systems. Eugenio Jacobo Hernandez Valdelamar. MCC
Thesis. Arturo Rosenblueth Foundation. 2003.