INSTRUCTION FETCH & EXECUTE MODEL – FROM INTEL’S PERSPECTIVE

9
CSC 5321: ADVANCED OPERATING SYSTEMS INSTRUCTION FETCH & EXECUTE MODEL FROM INTELS PERSPECTIVE

description

CSC 5321: ADVANCED OPERATING SYSTEMS

Transcript of INSTRUCTION FETCH & EXECUTE MODEL – FROM INTEL’S PERSPECTIVE

  • CSC 5321: ADVANCED OPERATING SYSTEMS

    INSTRUCTION FETCH & EXECUTE MODEL

    FROM INTELS PERSPECTIVE

  • 1

    A program to be executed by a processor comprises of a list of instructions stored in memory. A computer is built to execute instructions that are written in a very simple type of language called machine language. Different types of computers have their own machine language, and can execute a program only if it is expressed in that language. So to execute programs written in other languages, they need to be first translated (compiled) into machine language. For example, the following C language statement Will be translated to following assembly language: The assembly instructions are in turn translated into machine instructions. When the CPU wants to execute a program it first stores (by reading it from storage device) that program (in machine language format, of course) in the computer's main memory (RAM or random access memory). Along with the program, memory can also hold data that is being used or processed by the program. Main memory consists of a sequence of locations. These locations are numbered, and the sequence number of a location is called its address. An address provides a way of picking out one particular piece of information from among the millions stored in memory. The CPU executes a program that is stored as a sequence of machine language instructions in main memory. It does this by repeatedly fetching an instruction from memory and then executing that instruction. This process of fetch an instruction, executes it, fetch another instruction, execute it, and so on forever -- is called the fetch-and-execute cycle. As shown in Figure 1, our example assembly code is translated into machine language and loaded into the main memory. The program counter (PC) will hold the address of the next instruction to be executed (we are assuming that each machine instruction is encoded in such a way that it takes 4 bytes each). So, as in Figure 1, when the first instruction is ready to be executed (fetched from memory location and decoded) in the instruction register (IR), the PC is pointing towards the next instruction (PC=PC+4) in-line to be executed. Let us now take a detailed overview of the fetch and execution cycle. To start off the fetch cycle, the address which is stored in the PC is transferred to the memory address register (MAR). The CPU then transfers the instruction located at the address stored in the MAR to the memory buffer register (MBR) via the data lines connecting the CPU to memory. This transfer from memory to CPU is coordinated by the control unit (CU). To finish the cycle, the newly fetched instruction is transferred to the IR and unless told otherwise, the CU increments (by size of instruction) the PC to point to the next address location in memory. All these require several clock cycle to finish. After the CPU has finished fetching an instruction, the CU checks the contents of the IR and determines which type of execution is to be carried out

    a = b +c; // Sum variable b & c and put the result into a

    load R3, b // Copy the value of b from memory to register R3 load R4, c // Copy the value of c from memory to register R4 add R3, R4 // Sum the contents of register R3 & R4 // Sum will be placed in register R3 store R3, a // Store the value of register R3 into memory cell a

  • 2

    Figure 1. The PC, IR and RAM next. This process is known as the decoding phase. The decoding phase performs different checks such as, whether the instruction is a privileged instruction, whether the processor have proper access to execute that instruction, is it a trap instruction etc. If the decoding phase finds any such anomalies, it will raise an exception. The CU will save the current PC value (so that after the exception is handled, the program could resume execution at the place after the exception raised instruction) and load the PC with the corresponding Interrupt Service Routines (ISR) start address and move to the kernel segment, so that the exception could be handled in the proper way. If everything is alright in the decoding phase then the instruction is now ready for the execution cycle. After the instruction is executed (the execution step is complex and detailed in its own context, which we are not describing for simplicity), the CU checks for any interrupts happened? If no interrupts are there to handle, then the next instruction will be fetched and the fetch and execution cycle continues again. On the other hand, if there is an interrupt to handle, then the CU will save the current PC value (so that after the interrupt is handled, the program could resume execution at the right place where it was suspended) and load the PC with the corresponding Interrupt Service Routines (ISR) start address and set the segment value to kernel segment, so that the interrupt could be handled in the proper way (interrupt must be handled in supervisor mode).

    Figure 2 shows the flowchart for the generic fetch and execute cycle and Figure 3 shows one for Intel Architecture. As Intel do not have any user/supervisor bit, the mode checking is complicated and we only show few important checks that the fetch & execute cycle performs. In case of a Trap instruction, there should be mechanisms by which the user program that performs the Trap could get the control back. Intel uses instruction RTE (Return from Exception) at the end of any Trap or exceptions, which recover the processs context and change to user segment.

    Fetch & Execute Logic

    3050

    load R3, b

    PC

    IR

    CPU

    load R3, b load R4, c add R3, R4 store R3, a

    1011111000101010..1

    1011111000110011..0

    1111101010101010..1

    1010110001010101..1

    3046

    3050

    3054

    3058

    RAM

    Memory Address

    Machine language

  • 3

    Figure 2: Generic Instruction Fetch & Execution Cycle

    Start

    Yes

    No

    IN HARDWARE IN HA

    RD

    WA

    RE

    Yes

    Yes

    No

    No

    Fetch an instruction from a memory address, found

    in the PC

    Load the instruction to IR

    Increment the PC, so that it will now point to the next

    instruction in memory

    Decode instruction in IR

    Any Interrupt ?

    Save current PC

    Load PC with a pre-determined value

    Set user/supervisor bit to 1

    Privileged ?

    U/S bit=1 ?

    Save current PC

    Load PC with a pre-determined value

    Set user/supervisor bit to 1

    Execute instruction in IR

  • 4

    Figure 3: Instruction Fetch & Execution Cycle in Intel Architecture

    Yes

    Yes

    No

    Yes No

    Yes

    No

    Yes No

    Yes

    IN HARDWARE

    No

    Start

    Fetch an instruction from a memory address, found in

    the PC

    Load the instruction to IR

    Increment the PC, so that it will now point to the next

    instruction in memory

    Decode instruction in IR

    Any Interrupt ?

    Save current PC

    Load PC with a pre-determined value

    Set current segment = kernel segment

    Execute instruction in IR

    PC Address > PAGE_OFFSET

    ?

    Is it in Kernel Segment?

    ?

    Destination= mode register

    ?

    Is it in Kernel Segment

    ?

    Its a TRAP

    ?

    No

    Privileged ?

    U/S bit =1 ?

    Set U/S bit to 1

  • 5

    Figure 4. A BIOS chip in the motherboard

    When the computer is powered up, the CU in the CPU will start the fetch and execute cycle and will continue to do so, until the computer is powered down. After the computer is turned on, the processor is suffering from amnesia; there is nothing at all in the memory (PC) to execute. Of course the hardware makers know this will happen, so they pre-program the processor to always look at the same place (physical address 0xfffffff0) in the system BIOS (Basic Input Output System) ROM (a read only, persistent memory chip, Figure 4) for the start of the POST (Power on Self Test) program. So, when the system is powered on, the PC is pre-loaded with that hardwired address. So the instruction on that location will be loaded into IR and the PC will be incremented and the fetch and execute cycle will continue. This way all the instructions listed afterwards in the BIOS will be executed by the processor. The instructions in BIOS normally do various tests to check that all essential hardware components are fine and initialize them, and will then start the operating system booting process. It will choose a boot device (floppy, CD, Hard disk, USB etc.) in the order listed in the BIOS. If no available boot device is found, it will print an error message and will halt. The BIOS instruction will read the first sector of the available boot device. The first sector of the boot device is called the boot sector. The boot sector contains a small program (boot loader, such as LILO or GRUB or Operating systems own boot loader) whose responsibility is to read the actual operating system from the disk and start it. So, when the boot loader is completely loaded into RAM, the last BIOS instruction will be a jump instruction, that will jump to the first instruction of the boot loader and puts that into the PC. So, execution is now transferred to the boot loader and the fetch and execute will now continue from the first instruction of the boot loader. Figure 5 shows this overall picture.

    Figure 5: Intel System Initialization

    RAM

    POST

    BIOS

    ROM

    CMOS

    Boot Prog.

    OS

    Loader Boot Device Power Up

    Hardware Process

    Data Flow

  • 6

    After the loader completely loads the Linux kernel into the memory, it will first uncompress itself as the Linux kernel is installed compressed. This is due to several reasons but the important reason is that copying a small compressed kernel is much faster then copying a big uncompressed kernel. After that, the kernel does the following tasks to create a proper environment for user programs to run:

    Checks what hardware is there and configures some of its device drivers appropriately.

    Enable virtual memory/paging support. Do memory layout analysis and initializations. Initialize and enable interrupts. Do other initializations, such as, scheduling, timers etc. Mount root file system. Create the first kernel thread (init) that performs operating system environment

    initializations. Go into the idle loop, which is the loop executing when nothing else is to be

    scheduled. After all that the system is truly running and ready for user commands and user tasks. It will then print a prompt so that user can login to the system and run their processes. Figure 6 shows the overall sketch of the system booting process in Linux.

  • 7

    Boot Process with Linux (Kernel 2.4.x)

    Figure 6: PC boot process and kernel source code accessed during booting.

    ENVIRONMENT INITIALIZATION

    KERNEL STARTUP

    STARTUP

    Power On

    BIOS POST

    Startup initialization in file: arch/i386/boot/setup.S

    Uncompressed kernel head: Kernel source:

    arch/i386/kernel/head.S

    Kernel source: init/main.c

    init thread Kernel source: init/main.c

    Either Linux boot loader in file: arch/i386/boot/bootsect.S

    Boot loaders, such as LILO or GRUB

    Compressed kernel head: arch/i386/boot/compressed/head.S

    idle loop Kernel source:

    arch/i386/kernel/process.c

    Ready to rock & roll

    Nothing to do

  • 8

    References: 1. The Fetch and Execute Cycle: Machine Language, http://math.hws.edu/javanotes/

    c1/s1.html. 2. Operating Systems, Gary Nutt, Addison Wesley Publication, Third Edition, 2004. 3. Operating Systems, William Stallings, Prentice Hall Inc., 1995. 4. The Linux System Administrator's Guide, Version 8, Lars Wirzenius, http://www.tldp.org/

    LDP/sag/sag.pdf. 5. Linux Red Hat 9 Reference Guide, http://www.redhat.com/docs/manuals/linux/RHL-9-

    Manual/pdf/rhl-rg-en-9.pdf. 6. Linux Kernel 2.4 Internals, Tigran Aivazian, http://www.moses.uklinux.net/patches/lki.html. 7. The Linux/i386 boot protocol, Linux Redhat Source Code, Documentation/i386/boot.txt.