Hubbry Logo
Program counterProgram counterMain
Open search
Program counter
Community hub
Program counter
logo
8 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Program counter
Program counter
Program counter
View on Wikipedia
from Wikipedia

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.

The program counter (PC),[1] commonly called the instruction pointer (IP) in Intel x86 and Itanium microprocessors, and sometimes called the instruction address register (IAR),[2][1] the instruction counter,[3] or just part of the instruction sequencer,[4] is a processor register that indicates where a computer is in its program sequence.[5][nb 1]

Usually, the PC is incremented after fetching an instruction, and holds the memory address of ("points to") the next instruction that would be executed.[6][nb 2]

Processors usually fetch instructions sequentially from memory, but control transfer instructions change the sequence by placing a new value in the PC. These include branches (sometimes called jumps), subroutine calls, and returns. A transfer that is conditional on the truth of some assertion lets the computer follow a different sequence under different conditions.

A branch provides that the next instruction is fetched from elsewhere in memory. A subroutine call not only branches but saves the preceding contents of the PC somewhere. A return retrieves the saved contents of the PC and places it back in the PC, resuming sequential execution with the instruction following the subroutine call.

Hardware implementation

[edit]

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

[edit]

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

[edit]

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

[edit]

Notes

[edit]

References

[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Program counter

View on Grokipedia
from Grokipedia
The program counter (PC), also known as the instruction pointer (IP) in certain processor architectures such as x86, is a special-purpose register within a computer's (CPU) that stores the of the next machine instruction to be fetched and executed. This register is essential for maintaining the sequential flow of program execution, incrementing automatically after each instruction fetch to point to the subsequent address in . In the CPU's fetch-decode-execute cycle, the program counter directs the processor to retrieve the instruction from the specified memory location, after which it is typically updated—either by incrementing for linear execution or by loading a new value for operations like branches, jumps, or interrupts. The PC's value is critical for ensuring orderly instruction processing, and its manipulation enables features such as subroutine calls, loops, and in computer programs. Without the program counter, the CPU would lack a mechanism to track execution progress, rendering sequential or conditional program flow impossible. Historically, the concept of the program counter emerged with early stored-program computers like the in the late 1940s, where it formalized the addressing of instructions in to support principles. Modern implementations vary by architecture—for instance, in RISC processors like , the PC may be accessible as a general register, while in CISC designs, it often operates more opaquely—but its core function remains invariant across systems. The program counter's reliability is vital for system stability, as corruption of its value, often resulting from vulnerabilities like buffer overflows, can lead to crashes or unauthorized code execution via control-flow hijacking.

Fundamentals

Definition and Purpose

The program counter (PC), also known as the instruction address register, is a special-purpose register within a computer's central processing unit (CPU) that holds the memory address of the next instruction to be fetched and executed by the processor. This register is essential for directing the CPU to the precise location in memory where the subsequent machine instruction resides, facilitating the processor's ability to retrieve and process code in a structured manner. The primary purpose of the program counter is to ensure the orderly and sequential execution of instructions by maintaining a pointer to the current position in program memory; after each instruction is fetched, the PC is incremented to point to the next address, thereby preserving the linear flow of program execution unless altered by specific control operations. This mechanism allows the CPU to progress through a program's instructions in the intended order, supporting reliable computation without manual intervention for each step. The PC's role is integral to the instruction fetch-decode-execute cycle, where it initiates the fetch phase by providing the target address. In the context of the von Neumann architecture, the program counter enables the stored-program concept by treating instructions and data within the same unified address space, allowing the CPU to fetch executable code from memory locations just as it accesses operands. This design, proposed in John von Neumann's 1945 report on the EDVAC computer, revolutionized computing by making programs modifiable and stored alongside data, with the PC serving as the dynamic locator for sequential instruction retrieval. For instance, in a basic CPU initialization, the PC is often set to the program's entry point, such as memory address 0x0000, from which it advances incrementally—typically by the fixed size of each instruction—to execute the code in sequence.

Basic Operation in Instruction Execution

The program counter (PC) is integral to the CPU's instruction execution cycle, which encompasses the fetch, decode, and execute stages. In the fetch stage, the CPU retrieves the instruction located at the held in the PC and loads it into the (IR). This process ensures that the processor executes instructions in the intended sequence stored in memory. After fetching the instruction, the PC is automatically incremented by the of the fetched instruction to prepare for the next one. For instance, in byte-addressable with fixed-length 32-bit instructions, the PC advances by 4 bytes; in contrast, byte-addressable systems with variable-length instructions adjust based on the specific instruction . The decode stage then analyzes the IR contents to identify the operation, operands, and any required resources, while the execute stage performs the or access as specified, without altering the PC in sequential cases. PC updates follow specific rules to maintain program flow. For linear execution, the increment occurs post-fetch, as illustrated in this pseudocode:

Fetch: IR ← Memory[PC] PC ← PC + sizeof(instruction)

Fetch: IR ← Memory[PC] PC ← PC + sizeof(instruction)

This simple operation supports sequential processing. However, control instructions like jumps or subroutine calls explicitly load a new address into the PC, overriding the increment to redirect execution. If the PC references an invalid memory address during fetch—such as unmapped or protected regions—it triggers a hardware fault or exception, interrupting execution and transferring control to an operating system handler for resolution.

Hardware Aspects

Physical Implementation

The program counter (PC) is physically realized as a dedicated register array composed of flip-flops or latches, each bit position storing one element of the instruction in . This design enables stable storage of the address value until updated on the clock edge, preventing from asynchronous noise. In modern 64-bit processors, the PC spans 64 flip-flops to handle addresses up to 2^64 bytes, aligning with the architecture's addressing capabilities. Supporting circuitry includes a binary adder for incrementing the PC by the length of the instruction in bytes (e.g., 4 in 32-bit RISC architectures)—during sequential execution, ensuring the next instruction is fetched promptly. route either the incremented value or an external (e.g., from a target) to the PC input, selected by control signals from the instruction decoder. For example, in the Rice educational processor, the 8-bit PC employs an 8-bit incrementer using an S-R for overflow detection and a 16-to-8 built from 2-to-1 units to choose between current PC and data. Clock synchronization governs PC updates, with flip-flops triggered on rising or falling edges to coordinate with the CPU's fetch cycle and maintain timing integrity across the chip. In pipelined designs, the PC generates addresses for concurrent instruction fetches in multiple stages, incorporating buffers to mitigate propagation delays and branch prediction logic to reduce stalls from control hazards. This integration optimizes throughput while managing power by limiting unnecessary increments or loads only when control signals assert. A representative early implementation appears in the 8-bit , where the 16-bit PC comprises two cascaded 8-bit registers with internal carry propagation logic to form the full address for its 64 KB space.

Integration with CPU Components

The program counter (PC) primarily outputs its value to the memory address bus to facilitate instruction fetching, where it is first loaded into the () before being transmitted to main memory via the address bus. This connection ensures that the address of the next instruction is accurately directed to the memory subsystem for retrieval. The PC receives inputs through dedicated load paths, such as from (ALU) computations that generate branch targets or from immediate values in branch instructions, allowing it to update to a new address when changes. It interacts closely with the (IR), as the fetched instruction from the address specified by the PC is loaded into the IR for subsequent decoding and execution. During subroutine calls and returns, the PC collaborates with the stack pointer (SP); on a call, the current PC value (or PC incremented) is pushed onto the stack using the SP to save the return address, while on return, the saved address is popped from the stack and loaded into the PC. In terms of bus protocols, the PC drives the address lines on the shared address bus, often in conjunction with other registers like the MAR, enabling multiplexed access where the bus selects the PC's output for instruction fetch cycles. In pipelined or multi-core systems, bus mechanisms, such as priority encoders or round-robin schedulers, manage contention when multiple components (including multiple PCs in multi-core setups) attempt to drive the address bus simultaneously, preventing conflicts and ensuring orderly access to . For example, in RISC architectures like MIPS, the PC feeds directly into the fetch unit, where its value is updated and latched at the end of each clock cycle to maintain and avoid race conditions between fetch and execution stages. This clock-edge alignment ensures that the PC increment—typically adding the instruction length—occurs reliably without overlapping with ongoing fetches.

Architectural Consequences

Impact on Machine Design

The width of the (PC) fundamentally constrains the maximum addressable space in a processor, as it determines the range of addresses that can be directly referenced for instruction fetch. For instance, a 32-bit PC limits the system to 2^{32} or 4 gigabytes of addressable memory, necessitating additional mechanisms like paging or segmentation for larger systems. This design choice influences overall architecture by dictating depth and bus widths, where narrower PCs reduce hardware overhead but cap scalability, as seen in early 32-bit architectures transitioning to 64-bit for terabyte-scale addressing. In pipelined processors, particularly superscalar and designs, PC updates occur dynamically during the fetch stage to sustain high instruction throughput, but control hazards like branches introduce delays that can stall the . To mitigate this, branch mechanisms forecast the next PC value, allowing to overlap fetch with resolution; mispredictions flush the , incurring penalties proportional to pipeline depth. In execution, the PC is managed by the front-end fetch unit, which increments or redirects it based on predicted , decoupling it from execution completion to maximize parallelism while ensuring precise state recovery on exceptions. These adaptations highlight how PC handling shapes efficiency, with prediction accuracy directly impacting in modern CPUs. Security features like (ASLR) leverage the PC's role in address generation to thwart exploits, by randomizing the base addresses of code segments at load time, making it difficult for attackers to predict instruction locations for or . ASLR perturbs the , altering effective PC targets during execution and increasing the entropy required for successful memory corruption attacks. This integration into machine design enhances resilience against buffer overflows but demands compatible hardware support for randomized mapping without performance degradation. Designing wider PCs enables larger address spaces but introduces trade-offs in power consumption and silicon area, as broader registers and address buses require more transistors and wiring, escalating dynamic switching energy and static leakage. For example, extending from 32-bit to 64-bit PC widths increases energy demands in components like file due to larger sizes and port configurations, contributing significantly to overall CPU power budgets in high-performance systems. These costs also elevate expenses due to greater die area, prompting optimizations like Gray encoding for PC counters to minimize transition activity and power during increments. Thus, architects balance PC width against efficiency constraints, often favoring 64-bit standards for modern despite the overhead.

Role in Control Flow and Branching

The program counter (PC) plays a pivotal role in managing non-sequential execution by altering its value to direct the processor to different instructions, thereby implementing mechanisms such as branches and jumps. In unconditional jumps, the PC is directly loaded with a target specified in the instruction, immediately transferring control without evaluating any conditions. For conditional branches, the PC is updated only if a specified condition—such as a in the processor status register being set—is met; otherwise, it proceeds with its normal increment. In such cases, the new PC value is typically computed as the current PC plus a sign-extended offset, enabling relative for efficient code organization: \text{new_PC} = \text{current_PC} + \text{sign-extended_offset} This formula allows branches to reference nearby instructions without absolute . Subroutine calls extend this by first pushing the current PC () onto the stack before loading the target subroutine into the PC, facilitating a return via stack pop. Interrupt handling further demonstrates the PC's role in asynchronous control transfers, where external events suspend normal execution. Upon detecting an , the processor automatically saves the current PC (along with status information) to the stack or a designated area, then loads a new PC value from an that points to the handler routine's . After the handler completes its task, the saved PC is restored from the stack, resuming the interrupted program from the precise point of suspension. This mechanism ensures reliable context switching without , with vector tables serving as a fixed mapping of interrupt types to handler addresses. To mitigate performance penalties from frequent branches and interrupts, modern processors employ prediction mechanisms centered on the PC. The branch target buffer (BTB) is a cache that associates recent PC values of branch instructions with their predicted target addresses and outcomes (taken or not taken), allowing the fetch unit to speculatively load instructions from the anticipated next PC before resolution. If a misprediction occurs—such as an incorrect target guess—the flushes incorrect instructions and corrects the PC, incurring a penalty proportional to pipeline depth; the BTB reduces these by caching historical patterns, improving overall throughput in branch-heavy code. In the x86 architecture, the JMP instruction exemplifies direct PC manipulation for unconditional jumps, loading the specified target address directly into the EIP (extended instruction pointer, the 32-bit PC equivalent) without saving return information, thus enabling arbitrary control transfers. Relative variants of JMP or conditional jumps like JE (jump if equal) apply the offset formula to the current EIP, supporting compact encoding for loops and decisions common in compiled code.

Programming Implications

Representation in Low-Level Code

In low-level assembly languages, the program counter (PC) is manipulated primarily through dedicated and jump instructions that alter the flow of execution by updating the PC to a new . In x86 architecture, instructions such as JMP (unconditional jump) directly load a specified into the instruction pointer (EIP in 32-bit mode or RIP in 64-bit mode), while CALL pushes the current PC onto the stack and sets the PC to the target subroutine for function invocation. Similarly, in ARM architecture, the () instruction unconditionally sets the PC to a target , and BL ( with link) performs the same while saving the return address in the (R14). These operations enable explicit control over the PC without intermediate register loads in most cases, though indirect manipulation occurs when addresses are computed in general-purpose registers before . PC-relative addressing modes further integrate the PC into low-level code by calculating effective addresses as offsets from the current PC value, facilitating that remains functional across memory relocations. In , RIP-relative addressing encodes operands as signed offsets added to the RIP, commonly used in instructions like MOV or LEA for accessing global data without absolute addresses. supports PC-relative addressing in load/store instructions such as LDR (load register), where the offset is added to the PC (R15) to fetch data from a nearby location, typically within ±4KB in state or larger ranges in via ADRP/ADD combinations. This mode is essential for compact, relocatable binaries, as the assembler resolves labels to offsets during linking without embedding fixed addresses. During debugging, tools like the GNU Debugger (GDB) provide visibility into the PC's value, allowing developers to inspect and trace execution. In GDB, the command print $pc displays the current PC address in the selected frame, while x/i $pc disassembles the instruction at that location, aiding in step-by-step analysis of . This feature is particularly useful for verifying branch targets or diagnosing infinite loops where the PC repeatedly cycles through addresses. A representative example of PC manipulation appears in assembly loops, where conditional jumps implicitly update the PC based on flags set by comparison instructions. Consider this simplified loop that decrements a register until zero:

loop_start: cmp rax, 0 ; Compare RAX to 0, sets flags je loop_end ; Jump if equal (ZF=1), updates RIP to end sub rax, 1 ; Decrement RAX jmp loop_start ; Unconditional jump back, sets RIP to start loop_end:

loop_start: cmp rax, 0 ; Compare RAX to 0, sets flags je loop_end ; Jump if equal (ZF=1), updates RIP to end sub rax, 1 ; Decrement RAX jmp loop_start ; Unconditional jump back, sets RIP to start loop_end:

Here, the PC advances sequentially through instructions unless altered by JE or JMP, which compute targets relative to the current RIP for the backward branch. In ARM, an equivalent uses BNE (branch if not equal) for the condition:

loop_start: cmp r0, #0 ; Compare R0 to 0 beq loop_end ; Branch if equal, updates PC to end sub r0, r0, #1 ; Decrement R0 b loop_start ; Branch back, PC-relative offset to start loop_end:

loop_start: cmp r0, #0 ; Compare R0 to 0 beq loop_end ; Branch if equal, updates PC to end sub r0, r0, #1 ; Decrement R0 b loop_start ; Branch back, PC-relative offset to start loop_end:

The branches employ PC-relative offsets, ensuring the loop relocates correctly.

Abstraction in High-Level Languages

In high-level programming languages, the program counter (PC) is abstracted away from developers, with compilers translating control flow constructs like if statements and while loops into low-level jumps and branches without exposing the underlying PC mechanics. For instance, a compiler processes an if statement by evaluating the condition and generating conditional jumps to skip or execute the corresponding code block, ensuring sequential execution while optimizing branch predictions for performance. Similarly, while loops are transformed into a structure involving a jump back to the condition test after the loop body, often using labels in intermediate representations to manage flow without direct PC manipulation. This abstraction allows programmers to focus on logic rather than hardware-specific addressing, as detailed in standard compiler design principles. At runtime, high-level languages indirectly influence the effective PC through mechanisms like exceptions and non-local jumps. , the setjmp and longjmp functions enable non-local gotos by saving and restoring the execution context, including the program counter, to jump to a previously saved state without following normal call-return semantics, which can abruptly alter across function boundaries. In managed environments such as those using garbage collection, the pauses all threads during collection (a "stop-the-world" phase), effectively halting the PC at the current instruction, scans for live objects, and then resumes execution from the paused point to continue program progress. These operations maintain the illusion of seamless execution while handling memory and error recovery behind the scenes. Virtual machines further encapsulate the PC by maintaining a separate virtual program counter distinct from the host hardware's PC. In the (JVM), each thread possesses its own PC register that points to the current instruction being executed, allowing the JVM to interpret or JIT-compile code while abstracting hardware details for platform independence. Likewise, the .NET Common Language Runtime (CLR) employs an instruction pointer within its execution engine to track progress through (CIL) instructions, managing in a virtualized manner before mapping to native execution. This separation enables portable code execution across diverse architectures. Despite these abstractions, limitations arise when high-level constructs mimic low-level control, potentially leading to . Overuse of statements in languages like can bypass variable initializations or scope rules, resulting in accesses to uninitialized objects or lifetime violations, which invoke undefined behavior per the language standard. Additionally, during error handling, stack unwinding in exception scenarios restores the PC context by propagating the exception up the call stack, destroying local objects and transferring control to matching handlers, ensuring proper cleanup without explicit PC management. These cases highlight the boundaries where breaks down, risking portability and correctness if not handled carefully.

Historical and Modern Variations

Origins and Evolution

The origins of the program counter trace back to the transition from wired-program machines to stored-program computers in the mid-1940s. The , completed in 1945, lacked an explicit program counter and relied instead on plugboards and program trays to control the sequence of operations among its functional units. This manual reconfiguration approach, involving physical patch cords to route control pulses, represented the limitations of early electronic before automated instruction sequencing became feasible. Key milestones emerged with the advent of stored-program architectures. The , operational in 1948, incorporated a denoted as "C," functioning as a program counter to manage instruction sequencing in its accumulator-based design. This was followed by the in 1949, which introduced a dedicated 10-bit instruction counter—essentially a program counter—to store the address of the next instruction in its system. By 1952, the formalized the program counter in a commercial context, using it within its electronic analytic to track instruction addresses in electrostatic storage tubes, marking the integration of such mechanisms into production scientific computers. The evolution of the program counter reflected broader architectural shifts, progressing from fixed-word addressing in early stored-program machines—where instructions occupied uniform memory slots—to variable-length addressing in later designs that accommodated diverse instruction formats for greater flexibility. The , outlined in the 1945 report, profoundly influenced this development by specifying a central with a sequence counter for fetching instructions from a unified , enabling sequential execution and branching. In contrast, the , implemented in machines like the , employed separate program and data memories but retained a program counter to sequence instructions within the dedicated program store. The term "program counter" first appeared in technical literature around 1946, with usage solidifying in the late 1940s and 1950s amid the shift to transistor-based systems that demanded precise instruction tracking. A significant advancement occurred in the with the rise of RISC designs, which introduced pipelined program counters to prefetch and overlap instruction execution, as seen in prototypes like the project, enhancing throughput in simplified instruction sets.

Differences Across Architectures

The program counter (PC) behaves differently in Complex Instruction Set Computing (CISC) and Reduced Instruction Set Computing (RISC) architectures, reflecting their design philosophies. In CISC systems like x86, the PC—known as the RIP register in 64-bit mode—increments by the variable length of the executed instruction, which can range from 1 to 15 bytes or more, enabling complex PC-relative addressing for branches and jumps that account for instruction size variability. This approach supports denser code but complicates decoding and pipelining due to the need to determine instruction boundaries dynamically. In contrast, RISC architectures such as use a fixed-length instruction format, typically 32 bits (4 bytes), so the PC increments by a constant 4 bytes per instruction (or 2 bytes in mode), promoting simpler, more predictable fetch stages and easier superscalar execution. Architectures also differ in memory organization, particularly between von Neumann and Harvard models. Von Neumann designs, prevalent in general-purpose processors like x86 and , employ a unified PC to address a single memory space for both instructions and data, which simplifies hardware but can create bottlenecks during simultaneous instruction fetch and data access. Harvard architectures, common in processors (DSPs), feature a dedicated program counter for instruction memory separate from data generators or pointers, allowing parallel access to instructions and data via distinct buses and improving throughput for tasks. For example, in ' TMS320C54x DSP family, the program controller includes a 16-bit PC that sequences instruction fetches from program memory while independent data address units handle access, exemplifying this modified Harvard structure. Modern processor extensions adapt the PC to handle larger address spaces and specialized domains. In x86-64, the RIP register expands to 64 bits, supporting a theoretical 2^64-byte linear address space (though implementations often limit virtual addressing to 48 bits for practicality), enabling execution of large-scale applications without segmentation constraints common in 32-bit x86. Embedded systems like the 8051 microcontroller use a simpler 16-bit PC to address up to 64 KB of program memory in a Harvard-like setup with separate code and data spaces, where the PC fetches opcodes from ROM while data operations use indirect addressing via registers like R0-R7 or DPTR. In AI accelerators such as Google's Tensor Processing Units (TPUs), the control unit employs a minimalistic CISC instruction set with about a dozen high-level operations (e.g., MatrixMultiply) to sequence tensor computations across systolic arrays, diverging from traditional PCs by focusing on deterministic, dataflow-driven execution rather than general-purpose branching. Emerging paradigms in introduce analogs to the PC through sequencing, eschewing classical sequential counters in favor of compiled circuit execution. Post-2020 highlights hybrid models where quantum circuits—sequences of unitary applied in superposition—replace the PC with classical compilation and runtime scheduling, as seen in dynamic circuit frameworks that link multiple quantum processors without a persistent instruction pointer. For instance, decomposition techniques break multi-qubit operations into native two-qubit for direct hardware execution, enabling scalable control without von Neumann-style linearity. This shift supports error-mitigated, parallel quantum operations, contrasting with classical PCs by leveraging entanglement and measurement for .

References

  1. https://www.techtarget.com/whatis/definition/program-counter
  2. https://personal.utdallas.edu/~dodge/EE2310/lec13.pdf
  3. https://www.clear.rice.edu/elec422/1996/bomb/finalmw.html
  4. http://homepage.cs.uiowa.edu/~jones/arch/hawk/overview.shtml
  5. https://protect.bju.edu/cps/docs/cps110/textbook/ch01s01.html
  6. https://www.cl.cam.ac.uk/events/EDSAC99/simulators/echo/flat.html
  7. https://developer.arm.com/documentation/ddi0087/latest/ch03s04s01
  8. https://crypto.stanford.edu/cs155old/cs155-spring11/lectures/03-ctrl-hijack.pdf
  9. https://www.uvm.edu/~cbcafier/cs2210/content/02_basics_of_architecture/fetch_decode_execute.html
  10. http://homepage.cs.uiowa.edu/~jones/assem/notes/04hawk.shtml
  11. https://vinci.cs.uiowa.edu/oam/oam.html
  12. https://diveintosystems.cs.swarthmore.edu/book/C5-Arch/von.html
  13. http://www.cs.wisc.edu/~adilgsm/cs252/Fall2017/lectures/lec04_vonneumann_model.pdf
  14. https://cs.wellesley.edu/~cs240/s21/lab/lab5/lab5overs.pdf
  15. https://diveintosystems.cs.swarthmore.edu/book/C5-Arch/instrexec.html
  16. https://cseweb.ucsd.edu/~ricko/CSE3/ch09.pdf
  17. https://bob.cs.sonoma.edu/testing/sec-progexec.html
  18. http://www.eecs.umich.edu/courses/eecs427/w07/cad6.pdf
  19. https://www.cs.cmu.edu/~bryant/pubdir/CMU-CS-18-122.pdf
  20. https://www.totalphase.com/blog/2023/05/what-is-register-in-cpu-how-does-it-work/
  21. https://www.cs.princeton.edu/courses/archive/spring08/cos126/lectures/23CPU.pdf
  22. http://ece-research.unm.edu/jimp/611/slides/chap3_1.html
  23. https://stackoverflow.com/questions/46646929/how-do-the-two-program-counter-registers-work-in-the-6502
  24. https://neuron.eng.wayne.edu/auth/ece2620_new/lectures/ece2620_unit_1.htm
  25. http://aturing.umcs.maine.edu/~meadow/courses/cos335/COA15.pdf
  26. https://www.bietdvg.edu/media/department/CS/data/learning-materials/Computer_organization_Notes.pdf
  27. https://webkemper1.cs.tum.edu/teaching/ss20/c%2B%2Bpraktikum/slides/lecture-01.1.pdf
  28. https://web.eecs.utk.edu/~jplank/plank/classes/cs360/360/notes/Assembler4/lecture.html
  29. https://users.ece.cmu.edu/~koopman/stack_computers/sec4_2.html
  30. https://www.jmc.edu/econtent/ug/4602_Computer%2520Organization%2520and%2520Architecture.pdf
  31. https://liberty.princeton.edu/Publications/phdthesis_ram.pdf
  32. https://csweb.wooster.edu/jmusgrave/cs210/Chapter_04.pdf
  33. https://cseweb.ucsd.edu/classes/fa14/cse240A-a/pdf/04/Gonzalez_Processor_Microarchitecture_2010_Claypool.pdf
  34. https://www.uvm.edu/~cbcafier/cs2210/content/07_memory_hierarchy/memory_interface.html
  35. https://www.cs.fsu.edu/~hawkes/cda3101lects/chap5/index.html
  36. https://ftp.cs.wisc.edu/sohi/papers/1995/ieee-proc.superscalar.pdf
  37. https://people.eecs.berkeley.edu/~kubitron/cs252/handouts/papers/alpha-circuit.pdf
  38. https://www.engineering.iastate.edu/~zzhang/courses/cpre585-f03/reading/smith-isca81-bpred.pdf
  39. https://www.scs.stanford.edu/nyu/05sp/sched/readings/asrandom.pdf
  40. https://wenke.gtisc.gatech.edu/papers/aslrguard.pdf
  41. https://dr.lib.iastate.edu/server/api/core/bitstreams/55c7fb37-8aa5-4957-84c7-b9631ea9a259/content
  42. https://www.cs.umd.edu/~meesh/411/CA-online/chapter/instruction-set-architecture/index.html
  43. https://users.ece.utexas.edu/~valvano/Volume1/E-Book/C12_Interrupts.htm
  44. https://acg.cis.upenn.edu/milom/cse240-Fall05/handouts/Ch05.pdf
  45. https://nsec.sjtu.edu.cn/data/MK.Computer.Organization.and.Design.4th.Edition.Oct.2011.pdf
  46. https://www.cs.columbia.edu/~smb/classes/s06-4118/l07.pdf
  47. https://www.cs.cornell.edu/courses/cs4410/2021sp/schedule/slides/03.White.pdf
  48. https://cs.nyu.edu/~gottlieb/courses/2000s/2009-10-fall/os2250/lectures/lecture-03.html
  49. https://www.cs.cmu.edu/afs/cs/academic/class/15740-s18/www/lectures/16-branch-prediction.pdf
  50. https://www.engineering.iastate.edu/~zzhang/courses/cpre581-f05/lectures/Lecture8-1p.pdf
  51. https://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-vol-2a-manual.pdf
  52. https://www.felixcloutier.com/x86/jmp
  53. https://developer.arm.com/documentation/dui0473/latest/overview-of-the-arm-architecture/program-counter
  54. https://developer.arm.com/documentation/107656/latest/Registers/Registers-in-the-register-bank/R15--Program-Counter--PC-
  55. https://developer.arm.com/documentation/dui0379/e/arm-and-thumb-instructions/ldr--pc-relative-
  56. https://developer.arm.com/documentation/100068/latest/Migrating-from-armasm-to-the-armclang-Integrated-Assembler/PC-relative-addressing
  57. https://sourceware.org/gdb/current/onlinedocs/gdb.html/Machine-Code.html
  58. https://cs.nyu.edu/~gottlieb/courses/2000s/2008-09-fall/compilers/lectures/lecture-12.html
  59. https://www.cs.cornell.edu/courses/cs4120/2021sp/notes.html?id=ir
  60. https://www.cs.usfca.edu/~galles/cs414S05/lecture/old2/lecture8.java.pdf
  61. https://web.eecs.utk.edu/~huangj/cs360/360/notes/Setjmp/lecture.html
  62. https://web.eecs.utk.edu/~mbeck/classes/Spring20-cs360/360/notes/Setjmp/lecture.html
  63. https://www.cs.cornell.edu/courses/cs4120/2022sp/notes/gc/
  64. https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-2.html
  65. https://www.cin.ufpe.br/~haskell/papers/Technical_Overview_of_the_Common_Language_Runtime-Meijer&Miller.pdf
  66. https://sites.tntech.edu/acrockett/2025/08/15/why-is-goto-bad-programming-practice-in-c/
  67. https://wiki.sei.cmu.edu/confluence/display/cplusplus/EXP54-CPP.%2BDo%2Bnot%2Baccess%2Ban%2Bobject%2Boutside%2Bof%2Bits%2Blifetime
  68. https://www.cs.fsu.edu/~langley/COP4020/2015-Summer/Lectures/8.html
  69. https://www.britannica.com/technology/computer/ENIAC
  70. https://ftp.arl.army.mil/~mike/comphist/61ordnance/chap2.html
  71. https://archive.computerhistory.org/resources/text/Knuth_Don_X4100/PDF_index/k-4-pdf/k-4-u2780-Computers-Univ-Manchester-pdf.pdf
  72. https://www.csse.canterbury.ac.nz/greg.ewing/bredsac/doc/00-About-EDSAC.html
  73. https://archive.computerhistory.org/resources/access/text/2018/02/102632810-05-01-acc.pdf
  74. https://dl.acm.org/doi/pdf/10.1145/800196.805975
  75. https://engineering.purdue.edu/~eigenman/reports/vN.pdf
  76. https://www.sciencedirect.com/topics/computer-science/von-neumann-architecture
  77. https://www.oed.com/dictionary/program-counter_n
  78. https://www2.eecs.berkeley.edu/Pubs/TechRpts/1982/CSD-82-106.pdf
  79. https://stackoverflow.com/questions/63791693/how-is-value-of-program-counter-incremented
  80. https://www.geeksforgeeks.org/computer-organization-architecture/computer-organization-risc-and-cisc/
  81. https://www.ti.com/lit/pdf/spru307
  82. https://www.analog.com/media/en/dsp-documentation/processor-manuals/adsp-21160_hwr_rev4.1.pdf
  83. https://www.intel.com/content/www/us/en/developer/articles/technical/intel-sdm.html
  84. https://ww1.microchip.com/downloads/en/DeviceDoc/doc4316.pdf
  85. https://cloud.google.com/blog/products/ai-machine-learning/an-in-depth-look-at-googles-first-tensor-processing-unit-tpu
  86. https://www.nature.com/articles/s41586-024-08178-2
  87. https://arxiv.org/pdf/2504.20291
Add your contribution
Related Hubs
Contribute something
User Avatar
No comments yet.