Program counter: Difference between revisions
imported>Guy Harris Undid revision 1296734078 by 129.205.124.208 (talk) - rv damage |
imported>Guy Harris Copyedit. Link the first occurrence of "instruction". A call instruction saves the PC; "caching" can be read as storing it for possible faster access, with the possibility of it being removed from the cache. Explicitly state that a return statement jumps to that saved value. |
||
| Line 1: | Line 1: | ||
{{Short description| | {{Short description |Register that stores where in a program a processor is executing}} | ||
{{More citations needed|date=February 2025}} | {{More citations needed|date=February 2025}} | ||
{{Use dmy dates|date=February 2020|cs1-dates=y}} | {{Use dmy dates|date=February 2020|cs1-dates=y}} | ||
[[File:IBM 701console.jpg|thumb|Front panel of an [[IBM 701]] computer introduced in 1952. Lights in the middle display the contents of various registers. The '''instruction counter''' is at the lower left.]] | [[File:IBM 701console.jpg|thumb|Front panel of an [[IBM 701]] computer introduced in 1952. Lights in the middle display the contents of various registers. The '''instruction counter''' is at the lower left.]] | ||
A '''program counter''' (PC)<ref name="CompArchOrg">{{cite book |title=Computer Architecture and Organization |last=Hayes |first=John P. |isbn=0-07-027363-4 |year=1978 |page=245|publisher=McGraw-Hill }}</ref> is a [[processor register |register]] that stores where a [[computer program]] is being executed by a [[Processor (computing)|processor]].<ref name="a238">{{cite book | last=Bates | first=Martin | title=PIC Microcontrollers | chapter=Microcontroller Operation | publisher=Elsevier | date=2011 | isbn=978-0-08-096911-4 | doi=10.1016/b978-0-08-096911-4.10002-3 | pages=27–44|quote=Program Counter (PC) is a register that keeps track of the program sequence, by storing the address of the instruction currently being executed. It is automatically loaded with zero when the chip is powered up or reset. As each instruction is executed, PC is incremented (increased by one) to point to the next instruction. }}</ref> It is also commonly called the '''instruction pointer''' (IP) in [[Intel]] [[x86]] and [[Itanium]] [[microprocessor]]s, and sometimes called the '''instruction address register''' (IAR),<ref name="Mead_1980" /><ref name="CompArchOrg"/> the '''instruction counter''',<ref name="IBM_1953" /> or just part of the instruction sequencer.<ref name="Katzan_1971" /> | |||
Usually, the | Usually, a PC stores the [[memory address]] of an [[instruction (computer science)|instruction]]. Further, it usually is incremented after fetching an instruction, and therefore [[Pointer (computer programming)|points]] to the next instruction to be executed.<ref name="Silberschatz_2018" /> For a processor that increments before fetch, the PC points to the instruction being executed. In some processors, the PC points some distance beyond the current instruction. For instance, in the [[ARM7]], the value of PC visible to the programmer points beyond the current instruction and beyond the [[delay slot]].<ref name="ARM_AG12" /> For modern processors, the location of execution in the program is complicated by [[instruction-level parallelism]] and [[out-of-order execution]]. | ||
By default, a processor fetches instructions sequentially from [[Computer memory |memory]], but a control transfer instruction changes the sequence by writing a value in the PC. A [[branch (computer science)|branch]] allows the next instruction to be fetched from elsewhere in memory. A [[function (computing)|function]] call not only branches but saves the value of the PC. A [[return statement|return]] restores the value of the PC to resume execution with the instruction following the call by branching to the saved value. A transfer that is conditional on the truth of some condition lets the computer follow a different sequence under different conditions. | |||
== Hardware implementation == | == Hardware implementation == | ||
| Line 40: | Line 38: | ||
== See also == | == See also == | ||
* | * {{Annotated link |Branch prediction}} | ||
* | * {{Annotated link |Instruction cache}} | ||
* | * {{Annotated link |Instruction cycle}} | ||
* | * {{Annotated link |Instruction unit}} | ||
* | * {{Annotated link |Instruction pipeline}} | ||
* | * {{Annotated link |Instruction register}} | ||
* | * {{Annotated link |Instruction scheduling}} | ||
* | * {{Annotated link |Program status word}} | ||
}} | |||
== References == | == References == | ||
Latest revision as of 22:19, 26 December 2025
Template:Short description Script error: No such module "Unsubst". Template:Use dmy dates
A program counter (PC)[1] is a register that stores where a computer program is being executed by a processor.[2] It is also commonly called the instruction pointer (IP) in Intel x86 and Itanium microprocessors, and sometimes called the instruction address register (IAR),[3][1] the instruction counter,[4] or just part of the instruction sequencer.[5]
Usually, a PC stores the memory address of an instruction. Further, it usually is incremented after fetching an instruction, and therefore points to the next instruction to be executed.[6] For a processor that increments before fetch, the PC points to the instruction being executed. In some processors, the PC points some distance beyond the current instruction. For instance, in the ARM7, the value of PC visible to the programmer points beyond the current instruction and beyond the delay slot.[7] For modern processors, the location of execution in the program is complicated by instruction-level parallelism and out-of-order execution.
By default, a processor fetches instructions sequentially from memory, but a control transfer instruction changes the sequence by writing a value in the PC. A branch allows the next instruction to be fetched from elsewhere in memory. A function call not only branches but saves the value of the PC. A return restores the value of the PC to resume execution with the instruction following the call by branching to the saved value. A transfer that is conditional on the truth of some condition lets the computer follow a different sequence under different conditions.
Hardware implementation
In a simple central processing unit (CPU), the PC is a digital counter (which is the origin of the term "program counter") that may be one of several hardware registers. The instruction cycle[8] begins with a fetch, in which the CPU places the value of the PC on the address bus to send it to the memory. The memory responds by sending the contents of that memory location on the data bus. (This is the stored-program computer model, in which a single memory space contains both executable instructions and ordinary data.[9]) Following the fetch, the CPU proceeds to execution, taking some action based on the memory contents that it obtained. At some point in this cycle, the PC will be modified so that the next instruction executed is a different one (typically, incremented so that the next instruction is the one starting at the memory address immediately following the last memory location of the current instruction).
Like other processor registers, the PC may be a bank of binary latches, each one representing one bit of the value of the PC.[10] The number of bits (the width of the PC) relates to the processor architecture. For instance, a “32-bit” CPU may use 32 bits to be able to address 232 units of memory. On some processors, the width of the program counter instead depends on the addressable memory; for example, some AVR microcontrollers have a PC which wraps around after 12 bits.[11]
If the PC is a binary counter, it may increment when a pulse is applied to its COUNT UP input, or the CPU may compute some other value and load it into the PC by a pulse to its LOAD input.[12]
To identify the current instruction, the PC may be combined with other registers that identify a segment or page. This approach permits a PC with fewer bits by assuming that most memory units of interest are within the current vicinity.
Consequences in machine architecture
Use of a PC that normally increments assumes that what a computer does is execute a usually linear sequence of instructions. Such a PC is central to the von Neumann architecture. Thus programmers write a sequential control flow even for algorithms that do not have to be sequential. The resulting “von Neumann bottleneck” led to research into parallel computing,[13] including non-von Neumann or dataflow models that did not use a PC; for example, rather than specifying sequential steps, the high-level programmer might specify desired function and the low-level programmer might specify this using combinatory logic.
This research also led to ways to making conventional, PC-based, CPUs run faster, including:
- Pipelining, in which different hardware in the CPU executes different phases of multiple instructions simultaneously.
- The very long instruction word (VLIW) architecture, where a single instruction can achieve multiple effects.
- Techniques to predict out-of-order execution and prepare subsequent instructions for execution outside the regular sequence.
Consequences in high-level programming
Modern high-level programming languages still follow the sequential-execution model and, indeed, a common way of identifying programming errors is with a “procedure execution” in which the programmer's finger identifies the point of execution as a PC would. The high-level language is essentially the machine language of a virtual machine,[14] too complex to be built as hardware but instead emulated or interpreted by software.
However, new programming models transcend sequential-execution programming:
- When writing a multi-threaded program, the programmer may write each thread as a sequence of instructions without specifying the timing of any instruction relative to instructions in other threads.
- In event-driven programming, the programmer may write sequences of instructions to respond to events without specifying an overall sequence for the program.
- In dataflow programming, the programmer may write each section of a computing pipeline without specifying the timing relative to other sections.
See also
- Template:Annotated link
- Template:Annotated link
- Template:Annotated link
- Template:Annotated link
- Template:Annotated link
- Template:Annotated link
- Template:Annotated link
- Template:Annotated link
References
<templatestyles src="Reflist/styles.css" />
- ↑ a b Script error: No such module "citation/CS1".
- ↑ Script error: No such module "citation/CS1".
- ↑ Script error: No such module "citation/CS1".
- ↑ Script error: No such module "citation/CS1".
- ↑ Harry Katzan (1971), Computer Organization and the System/370, Van Nostrand Reinhold Company, New York, USA, LCCCN 72-153191
- ↑ Script error: No such module "citation/CS1".
- ↑ Script error: No such module "citation/CS1".
- ↑ John L. Hennessy and David A. Patterson (1990), Computer Architecture: a quantitative approach, Morgan Kaufmann Publishers, Palo Alto, USA, Template:ISBN
- ↑ B. Randall (1982), The Origins of Digital Computers, Springer-Verlag, Berlin, D
- ↑ C. Gordon Bell and Allen Newell (1971), Computer Structures: Readings and Examples, McGraw-Hill Book Company, New York, USA
- ↑ Script error: No such module "citation/CS1".
- ↑ Script error: No such module "citation/CS1".
- ↑ F. B. Chambers, D. A. Duce and G. P. Jones (1984), Distributed Computing, Academic Press, Orlando, USA, Template:ISBN
- ↑ Douglas Hofstadter (1980), Gödel, Escher, Bach: an eternal golden braid, Penguin Books, Harmondsworth, UK, Template:ISBN
Script error: No such module "Check for unknown parameters".