The architecture (instruction set, memory organization, I/0, and bus structure) of most computers at the machine language level is primitive and awkward to program, particularly for input/output. To make this point more solid, think how floppy disk I/0 is done using the NEC PD765 compatible controller chips used on most Intel-based personal computers. (Throughout this blog we will use the terms "floppy disk" and "diskette" interchangeably.) We use the floppy disk as an example, because, although it is out of date, it is much simpler than a modem hard disk. The PD765 has 16 commands, each specified by loading between 1 and 9 bytes into a device register. These commands are for reading and writing data, moving the disk arm, and formatting tracks, as well as initializing, sensing, resetting, and recalibrating the controller and the drives.
The most fundamental commands are read and write, each of which needs 13 parameters, packed into 9 bytes. These parameters define such items as the address of the disk block to be read, the number of sectors per track, the recording mode used on the physical medium, the intersector gap spacing, and what to do with a deleted-data-address-mark. If you do not understand this complicated language, do not worry; that is exactly the point, it is rather obscure. When the operation is completed, the controller chip returns 23 status and error fields packed into 7 bytes. As if this were not enough, the floppy disk programmer must also be constantly aware of whether the motor is on or off. If the motor is off, it must be turned on (with a long startup delay) before data can be read or written. The motor cannot be left on too long, though, or the floppy disk will wear out. The programmer is thus forced to deal with the trade-off between long startup delays versus wearing out floppy disks (and losing the data on them).
Without going into the real details, it must be clear that the average programmer perhaps does not want to get too closely involved with the programming of floppy disks (or hard disks, which are worse). Instead, what the programmer wants is a simple, high-level abstraction to deal with. In the case of disks, a distinctive abstraction would be that the disk contains a collection of named files. Each file can be opened for reading or writing, then read or written, and finally closed. Details such as whether or not recording should use customized frequency modulation and what the current state of the motor is must not appear in the abstraction presented to the application programmer.
Abstraction is the key to managing difficulty. Good abstractions turn a nearly impossible task into two convenient ones. The first one of these is defining and implementing the abstraction. The second one is using these abstractions to solve the problem at hand. One abstraction that almost every computer user understands is the file. It is a valuable piece of information, such as a digital photo, saved e-mail message, or Web page. Dealing with photos, e-mails, and Web pages is easier than the details of disks, such as the floppy disk mentioned above. The job of the operating system is to produce good abstractions and then enforce and manage the abstract objects thus created. In this blog, we will talk a lot about abstractions. They are one of the keys to understanding operating systems.
This is very important point and worth repeating in different words. With all due respect to the industrial engineers who designed the Macintosh, hardware is ugly. Real processors, memories, disks, and other devices are very complex and present difficult, awkward, idiosyncratic, and inconsistent interfaces to the people who have to write software to use them. Sometimes this is because of the need for backward compatibility with older hardware, sometimes by reason of a wish to save money, but sometimes the hardware designers do not realize (or care) how much trouble they are causing for the software. One of the main tasks of the operating system is to hide the hardware and present programs (and their programmers) with nice, clean, elegant, consistent, abstractions to work with instead. Operating systems turn the ugly into the beautiful, as shown in following figure.
It must be noted that the operating system's real customers are the application programs (via the application programmers, of course). They are the ones who deal directly with the operating system and its abstractions. In contrast, end users deal with the abstractions provided by the user interface, either a command-line shell or a graphical interface. While the abstractions at the user interface may be similar to the ones provided by the operating system, this is not always the case. To make this point clearer, consider the normal Windows desktop and the line-oriented command prompt. Both are programs running on the Windows operating system and use the abstractions Windows gives, but they offer very different user interfaces. Likewise, a Linux user running Gnome or KDE sees a very different interface than a Linux user working directly on top of the underlying (text-oriented) X Window System, but the underlying operating system abstractions are the same in both cases.
In this blog, we will study the abstractions provided to application programs in great detail, but say quite little about user interfaces. That is a large and important subject, but one only peripherally related to operating systems.
Tagsoperating system, software, memory
- User-Space I/O Software
- Device-Independent I/O Software
- Device Drivers
- I/O SOFTWARE LAYERS
- PRINCIPLES OF I/O SOFTWARE
- Memory-Mapped I/O
- EXAMPLE FILE SYSTEMS
- Defragmenting Disks
- File System Backups
- Implementing Directories
- An Example Program Using File System Calls
- Backing Store
- IMPLEMENTATION ISSUES
- Shared Libraries / Mapped Files
- Page Size
- Load Control
- DESIGN ISSUES FOR PAGING SYSTEMS
- Summary of Page Replacement Algorithms
- Simulating LRU in Software
- The Least Recently Used (LRU) Page Replacement Algorithm
- The Not Recently Used Page Replacement Algorithm
- PAGE REPLACEMENT ALGORITHMS
- Managing Free Memory
- RESEARCH ON PROCESSES AND THREADS
- Modeling Multiprogramming
- Process States
- Process Termination
- Process Creation
- The Model of Run Time
- Large Programming Projects
- Header Files
- THE WORLD ACCORDING TO C
- System Calls for Process Management
- Ontogeny Recapitulates Phylogeny
- Smart Card Operating Systems
- Real-Time Operating Systems
- Handheld Computer Operating Systems
- Booting the Computer
- Multithreaded and Multicore Chips
- COMPUTER HARDWARE REVIEW
- The Fourth Generation (1980-Present) Personal Computers
- The Third Generation (1965-1980) ICs and Multiprogramming
- The Second Generation (1955-65) Transistors and Batch Systems
- The First Generation (1945-55) Vacuum Tubes
- HISTORY OF OPERATING SYSTEMS
- The Operating System as a Resource Manager
- WHAT IS AN OPERATING SYSTEM?
- Introduction To Operating System