1 / 11

Operating Systems - some basics

Operating Systems - some basics. An Operating System is a program (very large) intermediary between a user and the computer (hardware) intermediary between a user and the software Goals of an OS convenience (as we will see, OS’s are not essential, just a luxury)

quyn-hill
Download Presentation

Operating Systems - some basics

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Operating Systems - some basics • An Operating System is • a program (very large) • intermediary between a user and the computer (hardware) • intermediary between a user and the software • Goals of an OS • convenience (as we will see, OS’s are not essential, just a luxury) • efficiency (that is, time savings for both the computer and the user)

  2. Components of a computer • Hardware (as covered in Architecture) • Users • Application Programs • Operating System • The Operating System can be thought of as the governing body of the computer -- it allocates resources and controls the software • There is no adequate single definition of an OS • Instead, we will describe its capabilities

  3. Evolution of OSs (24.1) • Earliest computers had none • Programs run from the console by the programmer (who was the operator) • Load program into memory (manually by setting switches, from paper or punch card) • Set starting address and press execute switch • As program ran, display lights on the console would provide information about what was going on including if an error occured • No resources available originally, later on minimal resources added (punch card reader, tape drive)

  4. Early Compiling • When assemblers, compilers, linkers and loaders were introduced, the programmer would have more to do: • Load compiler (e.g. FORTRAN compiler) from tape to computer memory • Mount program to be compiled on tape or card reader • Run FORTRAN compiler to produce compiled program with the result stored on tape • Load compiled program into memory from tape and run program • All steps performed by programmer/user

  5. Simple Batch Systems • Due to the inefficiency of this situation, new ideas were tried out: • A professional computer operator is hired to remove the need for the programmer to sit in front of the computer (but the operator could not debug errors…) • Batch processing made available - group together all FORTRAN compilations so that they could all be performed while the FORTRAN compiler was loaded, next group together all COBOL compilations, etc… • This led to the Resident Monitor (the first real OS) which was always resident in memory. Its job would be to sequence programs, one after another in order

  6. Control Cards • In order to properly sequence the programs, the resident monitor would be told what to do based on control cards, special punch cards designation various commands • $FTN - execute FORTRAN compiler • $ASM - execute Assembler • $RUN - execute user program • $JOB - first card • $END - last card • See figure 24.2, page 793

  7. Resident Monitor • The RM required several abilities: • Control Card interpreter • Loader • I/O device drivers • During batch processing, RM reads a series of cards. If told to execute a program, control switches from monitor to the running program. When program terminates, control returns to RM • Note that programs may have to wait once submitted, turnaround time is time between submission and completion

  8. Overlapped CPU and I/O ops • Since I/O is typically slower than CPU, batch processing is inefficient whenever I/O takes place • One approach is to replace I/O with offline processing (I.e. delay I/O until after program terminates and then have a separate device perform I/O. For instance, save output to tape and later print it) • Spooling - similar idea where disk replaces tape • Multiprogrammed Batch Systems - a better solution is to perform multiprogramming - whenever a job needs I/O, start I/O process and suspend job, working on another job until I/O terminates and then switch back (see figure 1.4 p. 9) • CPU Scheduling - what job to execute next?

  9. Time-Sharing • Take multiprogramming one step further - since multiple programs are currently in memory at different points of execution, why make any program wait? Instead, switch off between them with some constant number of clock cycles • Also known (more commonly) as multitasking • This provides an element of interactiveness with the computer since you don’t have to wait your turn to run a program • On-line file system allows interactive access to both data and code

  10. Personal Computers • What might seem like a step backwards in computing is to again dedicate a computer to a single user • With PCs however, the reason for this is to provide a single user with reasonable computing power at a low cost • PCs first appeared in the 1970s and by the mid 1980s they had revolutionized both the computer industry and the world • In spite of being single user systems, PC OS’s can be quite complex

  11. Other Types of OSs • Parallel Systems - require multiprocessing OSs in which interprocess communication adds to the complexity of the OS • Asymmetric vs. symmetric multiprocessing • Distributed Systems - resource sharing and network communications are required • Real-time Systems - rigid time requirements on processor operation and flow of data

More Related