The hardware on which we run an operating system is itself a system; as such, it is composed of several subsystems:
|-------| | CPU | CPU CPU -- CPUs | | | \ / | MEM | MEM -- memory | | | | IOP-------IOP----- -- I/O processors | | | and a network | other | other | I/O | I/O -- devices |-------| TraditionalThe focus of a traditional operating system course is on a system with one CPU and no network. In this course, as suggested by the above figure, we will concentrate on systems that may include multiple CPUs, and indeed, systems that may include many computers interconnected by a network.
Control Registers Unit | PC | The program counter | | and ALU <------> |_______| Some operand registersWithin the CPU, we will be concerned with the set of registers visible to the programmer, and not such details as the presence or absence of pipeline stage registers, microprogram support registers, or other registers hidden inside the CPU.
The most important operation on the registers that will concerns us is that of context switching. This involves first saving all registers of one context and then restoring all registers to build a new context.
Context switching is accomplished in different ways on different processors. Some CPUs support single ``context switch'' or ``exchange jump'' instructions that save and restore the entire CPU state in a single instruction. Such instructions generally take, as operands, the address of a data structure in memory to be used for saving or restoring the CPU state.
Another approach to context switching is to first push all of the registers on the CPU stack, pushing the program counter first (usually as part of the execution of a procedure call or interrupt). Once all the registers are on the stack, changing the stack pointer to the stack of the new context, followed by popping the registers and then returning from interrupt or returning from the procedure will complete the context switch.
Operating systems must frequently contend with a different source of complexity in memory management, virtual addressing.
Virtual Memory Lens Real Memory
| | ---- | |
| | \ / | |
| | || | |
| | / \ | |
|_________| ---- |_________|
CPU's Memory
Viewpoint Management
Unit
A Memory Management Unit is present in most larger computer systems,
sometimes as a component of the CPU, and sometimes as a separate component.
This unit serves as the "lens" through which programs operating on the CPU
observe the memory. As with any lens, we can talk about the real world
and the image of the world as seen through the the lens, the virtual image.
The memory management unit contains registers that may or may not be part of the context:
If the MMU registers are saved and restored as part of the context switching operation, the operation takes longer and the operation changes the memory address space. If the switch does not save the MMU registers, it is fast, but both the old and new contexts must share the same address space.
This is why we see systems with two levels of processes -- lightweight or easy to switch threads that share address spaces with each other, and heavyweight and difficult to switch processes each of which has its own address space. This allows multiple processes acting on behalf of a single application to coexist at very low cost, while allowing separate address spaces to be allocated to each application.
* send( data, device ) -- output * data = get( device ) -- input * repeat until ready( device ) -- wait for transfer completeIn register I/O, data is tranferred is by the program, one byte or word at a time. I/O registers may be addressed as if they are memory locations, or there may be a distinct I/O address space. The device ready indication is typically communicated by one bit in a status register; other bits may be used to indicate error conditions or other aspects of the device state.
Users typically rely on operating systems to provide the following:
These three meanings of the word "file" are usually used without any clarifying comment, and you have to figure out, from context which meaning is intended.
Generally, there is some operation, such as open(f,name), that takes a file name and interprets it in a directory structure to deliver an open file object. This object may refer to a file on disk, or it may refer to something else such as a terminal, a communications line, or a window.
It should be noted that on some systems, a file on disk need not have any name in any directory structure.
Before UNIX, command language interpreterss were generally integral parts of the operating system, and many people mistakenly asserted that, quite naturally, each command language operation was identical to a system call.
In UNIX and most later systems, the command language interpreter, called a shell on UNIX, is merely an applications program. If you don't like it, you can write your own. Most commands in the command language are merely names of programs, and the user of the command language interprets the commands as if they were parameterized procedure calls, where the programs themselves are procedures.
Most users view the command language interpreter as part of the system, but for most purposes, the system views the command language interpreter as if it was a user program.
As an aside, note that in later versions of the UNIX, the system has a special relationship to the Bourne shell through the system command, but this is not a system call, it is just a user library routine that passes its argument to the Bourne shell.