Instruction execution


Most of the CPUs you will encounter in the UNIX world are designed to execute instructions in a similar manner. A typical instruction sequence (cycle) would contain the following steps to execute one machine language operation.

  • Check for an interrupt. See if there is an external device that needs attention. Based on the current priority of the processor and the priority of the request, this may result in an immediate "function call" to a special piece of code to handle this particular situation, in other words, take care of the other guy first.

  • Fetch the next instruction. Using the program counter (PC) value, get the instruction to be executed from memory and load it into the CPU where it can be interpreted.

  • Update the PC. Increment the program counter so that the next fetch will get the next instruction.

  • Verify that the instruction is a recognized and legal instruction.

  • Verify that the memory locations and registers requested for use by the instruction are accessible and available for use.

  • Execute the instruction. This may require getting data from memory (a load operation) and/or putting a value into memory (a store operation).

  • Now, loop back to the beginning and do it all over again.

Every CPU has to go through these basic steps to execute every single instruction. There are some tricks that hardware designers use to try to speed up this sequence, but you can't really get rid of any of the steps themselves .

Instruction pipelining

One common approach used to speed up instruction execution time is to overlap the steps of the instruction cycle. It may turn out that memory is not being used at all for the execution portion, so it would be more efficient to start the next fetch for the next instruction while the current instruction is being performed. This technique is known as "instruction pipelining."

To understand pipelining, think of an assembly line for automobiles. While one automobile is in the process of being built on the assembly line, several more will also be on the line, each at a different phase of its construction. The use of an assembly line doesn't necessarily speed up the manufacturing time of each individual car, but it has a dramatic effect on the overall production of the plant when measured over time.

As with the automobile assembly line, instruction pipelines do not make individual instructions run faster. However, a sequence of a dozen pipelined instructions may execute in the same amount of time needed to execute only a couple of nonpipelined instructions.

Imagine if one instruction had to go through all the way through the pipeline shown below before the next instruction could enter it. Next, imagine that five instructions could be in the pipeline at one time, each at a different stage in its execution.

Figure 15-1. Some Possible Instruction Pipeline Stages

graphics/15fig01.gif

Now, think in terms of millions of instructions pr second passing through the instruction pipeline and the value of pipelining becomes quite clear.

Floating-point coprocessors

Another way to speed up overall program execution is to use coprocessors for certain types of instructions. The most common example of this is a Floating-Point Unit, which is used only for handling floating-point operations. The CPU will normally recognize an instruction as something that should be handed over to the FPU, allowing the CPU to continue with the next instruction. The FPU does its work asynchronously, taking as much time as it needs and possibly signaling the main CPU when the operation is complete. The CPU can proceed with other work in parallel.

Note

Do not confuse this concept with multiprocessor systems. Here, the FPU coprocessor is dedicated to performing only certain tasks . A true multiprocessor system normally has several CPUs, each of which runs concurrently and may have its own FPU.




PANIC. UNIX System Crash Dump Analysis Handbook
PANIC! UNIX System Crash Dump Analysis Handbook (Bk/CD-ROM)
ISBN: 0131493868
EAN: 2147483647
Year: 1994
Pages: 289
Authors: Chris Drake

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net