Chapter 2, Introducing and Using RCOS
Please allow me to introduce myself
I'm a man of wealth and taste
-- Mick Jagger, Keith Richards
RCOS (pronounced AH-COS) stands for Ron Chernich's Operating System and was
written by Ron Chernich as a student project for the Department of Maths and
Computing at the Central Queensland University. RCOS was written specifically
for the subject 85349 and is being maintained and developed by CQU.
RCOS is a computer aided learning tool and a multi-tasking operating system.
As a computer aided learning tool it provides
- animation of the functions of a multi-tasking operating system,
- example implementation of algorithms and theory introduced during the
study of operating systems, and
- a platform for experimenting with different algorithms, data structures
and operating systems theory.
RCOS is also a full blown, multi-tasking operating system and performs the
majority of the tasks performed by such an operating system, process
management, terminal I/O, inter-process communication, disk drive management, a
simple file system and memory management.
The current implementation of RCOS sits on top of an existing operating system,
MS-DOS or UNIX. The reasons for placing RCOS on top of an existing operating
system rather than implementing it on a bare machine are
- to make the development of RCOS easier, and
Creating an operating system that rests on top of an existing operating system
is a standard technique used in the development of most operating systems. It
means that the operating system creators can make use of the platform's
debuggers and other programming tools to make the whole development process
simpler.
- to provide the graphical functions necessary for animating the operating
system.
RCOS is designed to be used as a learning tool and one of the methods used to
achieve this is animating the algorithms and data structures RCOS uses.
Sitting RCOS on top of an existing operating system provides the graphical and
input functions necessary to accomplish this.
With some extra effort RCOS could quite happily run as a normal operating
system sitting directly on top of the bare hardware of a machine. In fact at
some stage in the future we plan to do this (any students out there looking for
a project?).
The internal structure of RCOS will be explained in more detail in Chapter 6
while chapters 3 and 4 will introduce you to writing RCOS programs. Chapter 5
explains how to recompile RCOS on your system and chapter 7 describes the
process of modifying RCOS.
This chapter will provide you with a basic introduction to RCOS and with the
information necessary to use RCOS as an operating system.
The programs an operating system executes must be written in the machine
language format used by the operating system and hardware the operating system
is running on. The "machine language" that RCOS uses is called p-code
(pseudo code).
In order to produce a machine language program a compiler is used to translate
some higher level source code language into machine language (almost no-one
writes straight machine language). RCOS is distributed with a compiler, the
program pll2.exe, that compiles the source code language PLL/2 (Pascal Like
Language 2) into RCOS p-code.
The PLL/2 compiler will not execute under RCOS. Instead it must be executed
under your normal operating system (MS-DOS or UNIX). This means you must
compile your RCOS programs under DOS or UNIX before starting RCOS and
attempting to execute them.
Chapters 3 and 4 will introduce you to the PLL/2 language, its features, its
special features (including semaphores and shared memory) and the whole process
of writing, compiling and executing RCOS programs.
For the purposes of this chapter you will make use of a number of pre-compiled
p-code programs. These files are stored in the rcos directory created when you
installed RCOS (refer to chapter 1). Executable p-code programs will be in
files with the extension .pcd. The PLL/2 source files that were compiled to
produce the executable programs will have the extension .pll.
Exercises
2.1. Examine the contents of the files with .pll extensions in the RCOS
directory. Those of you with a Pascal background should be able to understand
some of what these programs are doing.
The user interface used by RCOS follows the same rules and provides the same
look and feel as Microsoft Windows (see Figure 2.1). Just like MS-Windows the
interface can be navigated by using either mouse or keyboard.
For example, the About push button in the bottom right of Figure 2.1 can be
activated by either
moving the mouse pointer over it and pressing the left mouse button,
or
using its hot key combination.
The hot key combination is always the ALT key plus the underlined character on
the control, for the About button it is ALT-A.
The RCOS display divides the screen into three basic components (see Figure
2.1)
-
a Title Bar,
The title bar is situated at the top of the screen and is used to
display messages about what RCOS is doing.
-
the operator's console, and
Located at the bottom of the screen this area is always the same and
contains an area for the operator to enter text and four push buttons. The
operator's console and the four push buttons are used to control the operation
of RCOS.
-
a display window controlled by four radio-buttons.
The contents of the display window can be any one of four different
screens depending on which radio-button is active.
Figure 2.1.
RCOS Resource Manager Screen.
The display window is used to view one of four available animations of
operating system action. The four animation displays are
the CPU Scheduler,
the Memory Manager (not implemented yet, yet another possible student
project),
the Resource Manager (currently displays the disk drive animation),
and
the Devices screen (displaying the available terminals).
This window (see Figure 2.1) is currently used to animate the scheduling of
disk drive accesses. It currently displays a queue containing current disk
access requests and a representation of a single platter disk drive.
Hitting the Run button will start the operating system part of RCOS executing.
After starting the operating system you should see the disk drive start
rotating (which it will do continuously) and a > prompt appear in the
operator's console.
Whenever there are requests by programs to access files on RCOS's simulated
disk drives the request will appear in the queue below the disk. Eventually
the operating system will schedule the request and pass it onto the disk drive
at which stage the read/write head will move.
Click here for Picture
Figure 2.2.
RCOS Devices Screen.
RCOS like most operating systems must provide some mechanism for user
input/output. The current mechanism employed by RCOS is a number of dumb
terminals (the actual number can be controlled by an entry in the rcos.ini
file) that allow simple text input/output. The representation of the dumb
terminals are contained on the Devices screen (Figure 2.2).
When you run an RCOS program if it requires any text input/output from the user
it will be allocated one of the two available terminals. Any text output will
be displayed on that terminal.
User input is passed to the process by making the appropriate terminal active
by pressing the terminal's radio button. Once the radio button is active
anything typed on the keyboard of your computer is treated is sent to the
terminal and from there to the process that owns the terminal.
Figure 2.4.
RCOS CPU Scheduler Screen.
The CPU Scheduler display window (shown in Figure 2.4) is used to animate RCOS'
process management system. It displays a number of process queues and a
representation of the current CPU state of the pseudo machine on which RCOS
programs run.
All the queues except for the Input Queue should be talked about in any
operating systems textbook. RCOS's Input Queue is used to hold processes that
have been created in memory but have not yet been made ready for execution by
the console operator (you).
The movement of the processes between the various queues and their various
states is animated. This allows you to follow the life cycle of processes
throughout the life cycle.
The memory manager animation screen has not been implemented at this time.
A recent addition to RCOS has been the incorporation of an initialisation file.
When you start RCOS it will look for a file called rcos.ini in the current
directory. Those of you familiar with Windoze (sorry, Windows) will recognise
the extension and the format of this file as it follows very closely that of
Windog ini files.
The default rcos.ini file will look like this
[RCOS]
quantum = 75 ; max milliseconds per process quantum
terminals = 4 ; number of user terminals (exc console)
display = devices ; Initial window to display
Any text that follows a ; is considered a comment and is ignored. At this
point in time there are three different labels that are recognised. quantum
controls how many milliseconds the process quantum will be.
terminals controls how many user terminals are created. The current memory
management scheme used by RCOS means that there is a possible maximum of 7
terminals. The current memory management scheme is a simple partitioned scheme
that only allows eight processes (one for the operator's console and one each
for seven terminals).
display controls which screen RCOS will display when it first starts.
In order to explain the operation of RCOS the following section takes you step
by step through an example session with RCOS.
During this session with RCOS we will execute two RCOS programs, primes and
ptest4. These two programs should already be in the main RCOS install
directory. In fact you should see in the install directory two files with the
name primes, one with a .pcd (the executable version) extension and the other
with .pll (the source code version) extension.
One file is the file which RCOS can execute and it will have a PCD extension.
The other file is the original source code from which the executable was
produced (extensions pll)
Exercises
2.2. Examine the contents of the two source code files and determine
what the two programs primes and ptest4 will do.
1. Start RCOS.
Start RCOS like you would any other executable program. You should find an
executable version of RCOS in the RCOS install directory.
2. Start the operating system simulation.
When you first start RCOS the actual operating system is not yet
running. To start it you must press the Run push button (either with the mouse
or by the keys ALT R).
If you wait long enough (how long you wait depends on which screen you see
when RCOS starts) you should see a > prompt appear in the operator's console
window at the bottom of the screen. This indicates that the operating system
portion of RCOS is up and going and you can start giving it instructions.
3. Select the CPU Display Window.
Change to the CPU Display Window by choosing the appropriate radio
button. You can do this using either the mouse or by the keys ALT-C (hold the
ALT key down and hit the C key).
You should see that Process 0 (represented by P0) is either moving to or is
resting in the blocked queue. Process 0 is the process that controls the
operator's console. Being in the block queue means that it is waiting for
something to happen.
Hit the enter key. You should see P0 move to the ready queue then to the CPU
and back to the blocked queue. P0 follows these simple steps, wait for
operator to hit enter (this means a command has been entered), get the command,
attempt to execute the command, wait for operator to hit enter again.
4. Run the PRIMES.PCD program.
Running a program under RCOS requires two steps.
Create the process.
The first step is to create the process. In this step, the code is loaded
from disk and placed into memory, all the necessary resources (memory etc) are
allocated and the process is placed onto the input queue.
To create a process you use the fi command (see Table 2.1).
Enter the command fi primes to create a process based on the PRIMES.PCD
program. If successful you should see P1 appear in the input queue.
An error message will appear in the Operator's console if the file
couldn't be found. This usually means that the current MS-DOS directory
doesn't contain the necessary .pcd program.
Make the process ready.
For the process to actually be executed it must be placed onto the
ready queue. You do this using the go command.
Move the new process onto the ready queue by entering the command go 1. (1 is
the number of the process) If successful you should see P1 move from the input
queue to the ready queue. From there it should move onto the CPU and commence
execution. Once it has been on the CPU for a set period of time (the quantum)
the process will be taken off the CPU and placed onto the ready queue.
5. View the output of the PRIMES.PCD program.
Change back to the Terminal display window by selecting the correct
radio button. The output from P1 should now be appearing onto the first
terminal.
6. Start up PTEST4.PCD.
Change back to the CPU Display window and start up the PTEST4 program
using the same process as that for primes.
fi ptest4
go 2
You should now see two processes (1 and 2) on the ready queue and sharing the
CPU. This sharing of the CPU is how multi-tasking operating systems simulate
many different processes running at the same time.
7. View the output of PTEST4.
Change back to the Terminal display and view the output of ptest4. You
should see the primes process still happily chugging away in its terminal.
While ptest4 has placed some output in its terminal and is now waiting for you
to input some numbers.
8. Give some input to PTEST4.
To give ptest4 the input it needs you should click on the radio button
associated with ptest4's terminal. Now you can enter the necessary input.
9. Stop the execution of P1 by using a user break.
Make the terminal in which P1's output is being displayed active by
selecting its radio button (use the mouse button or the keys ALT 1). All input
is now being sent to that terminal and then onto the process executing on that
terminal. Hit CTRL-C. This should generate the user break signal that will
cause P1 to die. If successful you should see the output stop appearing.
10. Check what's happening.
Change back to the CPU display window and discover what has happened to
P1. You should find the P1 no longer exists on the system. RCOS automatically
removed P1 from the system when it received the signal generated by the
CTRL-C.
And so ends your first session with RCOS. You should now be familiar enough
with RCOS to make simple use of it.
Exercises
2.3. Starting where you left off after the above example session perform
the following steps
* kill the PTEST4 process using the CTRL-C key combination,
* create and run two processes using the PRIMES.PCD
program,
* hit the step button and observe what happens
(you may have to hit the step button a couple of times)
Once you have activated the operating system a prompt will be displayed on the
operator's console. Overall control of the actions of RCOS is accomplished by
entering simple commands on this console.
The first process (P0) created everytime RCOS is run is in charge of the
operator's console. The operator's console process continually repeats the
following steps
display the console prompt,
block until the user hits the enter key,
look at what the user typed and see if it is a valid command,
if it is execute the appropriate command otherwise display an error
message.
Each operator command consists of a keyword, some followed by one or two
parameters (the parameters are mandatory). Commands may be entered in full, or
abbreviated to the first two letters of the command. If more than two
characters are used, the name must be complete and correctly spelt. Table 2.1
provides a summary of the operator console commands a more in-depth explanation
of each command follows afterwards.
In table 2.1. p-num stands for the process number 1, 2.... Process 0 is
always the process responsible for the operator's console.
Console Command Purpose
BATCH filename Execute a series of commands contained in a
file
DELETE p-num kill off a process (only if it isn't running)
DIE kill the operating system if there are now
user processes
FIND filename create a new processes from the p-codes
contained in the file and place it on the
input queue (no need for the PCD extension)
GO p-num move specified process from input queue to
ready queue
PRIORITY p-num new-pri change a processes priority
RESUME p-num place a suspended processes onto the ready or
blocked queues
SUSPEND p-num suspend a current process
Table 2.1.
System Console Commands.
All commands are checked for correct and valid parameters. In the best ICL
(the RCOS command language is based on a job control language of an ICL main
frame) traditions, mistakes result in incomprehensible diagnostic messages.
The codes produced by the RCOS console are detailed in Table 2.2.
Error Code Explanation
A Invalid command
B File not found
C Illegal or invalid process number
D Invalid priority value
E Incorrect number of parameters
F Unable to start process
G Unable to Die - User process still
active
Table 2.2.
System Console Error Codes.
BATCH filename
This executes a sequence of operator commands (the batch) contained in the
named file that must have the extension JOB. This command is not implemented
in the first release. It is intended that it will form the basis of a Job
Control Language (JCL). Used in conjunction with the system log, this will
permit repeatable timings of sequences of events to be derived, allowing
performance related modifications to the kernel and device drivers to be
evaluated.
DELETE process-number
The numbered process (which cannot be currently executing, think about it) is
killed off. All memory and devices allocated to it are released.
DIE
Kills the operating system itself, provided no user programs are still
running. Pressing ALT+F4 (or double-clicking the close gadget) is
similar, but ignores running programs.
This command was included by Ron for nostalgic purposes. Below is his
explanation of why. (ICL is/was a British manufacturer)
A favourite operator's trick, when an important audience was present, was to
type " DIE", with a leading space. This would cause a standard,
incomprehensible error message. The operator, now the assured centre of rapt
attention, would pause, think, then type "DIE YOU POMMY SOD" (or something like
that). The trailing text would be ignored, the machine would close down and
the audience would withdraw, marvelling at the skill of the operator and a
computer so smart, it knew of its origin.
FIND filename
The p-code program is loaded into the input queue for eventual execution using
the GO command. P-code programs have the extension PCD. The extension
need not be entered. In this release, if the program does not reside in the
same directory as the operating system, a host path must be included.
GO process-number
The numbered process is started, provided the resources it requires are
available. As each process is loaded into the Input Queue (with the FI
command), it is assigned a sequential process number. The console process
is the loaded and executed automatically when RCOS is started, becoming process
P0. The rest follow on. The lowest available number is always assigned.
NOTE: DO NOT ENTER THE "P". Only the number is required.
PRIORITY process-number new-priority
Each process is assigned a default priority as it is loaded. At context
switching time, the highest priority process free to run is dispatched to the
CPU. When the running processes' time quantum expires, its priority is
temporarily decremented and it is re-inserted into the Ready Queue. This is a
priority queue, sorted on process priority. After insertion, its priority is
incremented back to the original value. This assures that processes of equal
priority will execute round-robin. This simple scheme was borrowed from the
Microsoft Windows scheduler. Valid priority values are 0 to 99. The console
process has priority 100. For a good time, revise this to something very
low.
RESUME process-number
The numbered process is moved back to either the Ready or Blocked state
(see the SU command, below).
SUSPEND process-number
The numbered process (which must have been started, but cannot be currently
executing, obviously) is moved from its current state, either Ready, or
Blocked, to the corresponding suspended state. In this state it cannot be
scheduled for execution. Operators could then take away resources allocated to
the process (like a tape drive, line printer, etc), and give this resource to
another process. When that process completed, the resource could be given back
to the suspended process and the RESUME command issued. This provided a
most effective brute-force method of dead-lock recovery.
You should now have some vague idea of what RCOS actually is and possibly why
we will be using it. In addition you should have completed a first session
with RCOS and gained a basic understanding of how to operate RCOS. In addition
you should now know the basic functionality provided by the RCOS operator
console commands.
