Chapter07Rev08 - Chapter 7 (Revision number 8) Processor...

Info iconThis preview shows pages 1–3. Sign up to view the full content.

View Full Document Right Arrow Icon
1 Chapter 7 (Revision number 8) Processor Scheduling 7.1 Introduction Processor design and implementation is no longer a mystery to us! From the earlier chapters, we know how to design instruction-sets, how to implement the instruction-set using an FSM, and how to improve upon the performance of a processor using techniques such as pipelining. We turn our attention to a complementary topic, namely, how to manage the processor as a resource in a computer system. To do this, do we need to know the internals of the processor? Not really. That is the power of abstraction. We can consider the processor as a black box, an important and scarce resource, and figure out the software abstractions that would be useful in managing this scarce resource. Before we delve into this topic, let us first ask a very basic question. What is an operating system? It is just a program , written by smart people just like you! What does it do? Upon request, it gives the resources to execute users’ programs. What are the resource requirements of a user program? Let us review how we create programs in the first place. We know that a program written in a high-level language such as C has a memory footprint as shown in Figure 7.1. 7.2 Programs and Processes We use the term program in a variety of connotations. However, generally we use the term to denote a computer solution for a problem. The program may exist in several different forms. Figure 7.2 shows the life cycle of program creation in a high-level language. First, we have a problem specification from which we develop an algorithm. We code the algorithm in some programming language (say C) using an editor. Both the algorithm and the C code are different representations of the program , a means of codifying our solution to a problem. A compiler compiles the C code to produce a binary representation of the program. This representation is still not “executable” by a processor. Why? This is because the program we write uses a number of facilities that Use by the OS Program stack Program heap Program global data Program code Use by the OS Low memory High memory Memory footprint of User program Figure 7.1: Memory Footprint
Background image of page 1

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
2 we take for granted are supplied to us by “someone else”. For example, we make calls to do terminal I/O (such as scanf and printf ), and calls to do mathematical operations (such as sine and cosine ). Therefore, the next step is to link together our code with that of the libraries provided by someone else that fill in the facilities we have taken for granted. This is the job of the linker. The output of the linker is once again a binary representation of the program, but now it is in a form that ready for execution on the processor. Where do these different representations of your program (English text, unlinked binary, and executable binary) end up? They all go to your hard drive usually. Loader is another program that takes the disk representation and creates the memory footprint shown in Figure 7.1.
Background image of page 2
Image of page 3
This is the end of the preview. Sign up to access the rest of the document.

This note was uploaded on 11/25/2010 for the course CENG 100 taught by Professor Ceng during the Spring '10 term at Universidad Europea de Madrid.

Page1 / 21

Chapter07Rev08 - Chapter 7 (Revision number 8) Processor...

This preview shows document pages 1 - 3. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online