On Sat, 11 Jun 2011 18:56:12 -0400, Farley, Peter wrote: >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On >> Behalf Of Lindy Mayfield >> Sent: Saturday, June 11, 2011 6:28 PM > >> Someday I'll take the time to try to understand what "pipeline" means. >> You guys talk about that a lot.
You can think about it this way. Suppose you are designing a processor. In order to process instructions, there are several things that have to be done. Something like this: 1. Fetch the next instruction from memory 2. Decode the OP code 3. Fetch the operands 4. Perform the operation specified on the operands 5. Store the result. These steps can simply be performed in sequence, with the fetch of the second instruction following the store of the results of the first instruction. Now, suppose that you design it with separate hardware for each of the above steps. After the first instruction is fetched from memory, it goes on to the instruction decoder. While the instruction decoder is figuring out what the OP code means, the instruction fetcher can fetch the second instruction. Then the operand fetcher can fetch the operands for the first instruction. At the same time, the decoder can decode the second instruction and the instruction fetcher can fetch the third instruction. Next, the first instruction performs the operand specified on its operands. At the same time, the operands are fetched for the second instruction, the third instruction is decoded and the fourth instruction is fetched from memory. Finally, the results of the first instruction are stored in memory. At the same time, the second instruction performs its operation on its operands, operands are fetched for the third instruction, the fourth instruction is decoded and the fifth instruction is fetched from memory. That is a pipeline. You probably realized when reading this that there are situations where the pipeline has to wait for something. For example, if the second instruction uses the results of the first instruction, the operands for the second instruction can not be fetched as described above. That causes the pipeline to stall. Pipelines on modern processors are considerably more complex than what I have described here, but I hope you get the idea. >A CPU pipeline is the hardware advance that makes measuring program >CPU time a gambler's game, since there is no longer any guarantee at >all that a program will consume the same CPU time from one execution >to the next, even with totally identical inputs. Actually, it is not so much the pipeline that makes the execution times for an instruction unpredictable, but the variability in the time required to access memory. Modern processors have small, high speed memory called cache that the processor can access quickly. If the data is not there, it has to try a second or third level cache, each of which takes more time to access. If the data can not be found there, it has to be fetched from main memory, which is _much_ slower. The processor must wait for it, and that wait is part of the execution time for the instruction being processed. Virtual memory translation also takes time, because it involves even more memory accesses, but Translation Lookaside Buffers reduce the need to perform page table lookups. -- Tom Marchant ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
