![]() | This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||
|
This thing doesn't count programs. It counts instructions.
Wait, it doesn't count either. It jumps around in response to various events and instructions. IA-32 examples: call, ret, int, syscall, sysenter, sysret, iret...
So it's not a counter. It's a pointer.
Well gee. That must be why Intel called it the instruction pointer in their documentation.
OK, never mind the most popular CPU architecture. What about the Mac or Xbox/360? There we have the next instruction pointer register, and current instruction pointer as a concept in the documentation.
24.110.60.225 00:46, 1 January 2006 (UTC)
I have been reading a bit in my course book about computer hardware and found the following information:
8086/8088 processors have a 16 bit data bus and a 20 bit address bus, so two registers are needed to contain an address: a segment register and an offset register. The memory address can be obtained by bit-shifting the segment register by four bits to the left and performing a summation with the offset register. The memory a program used is seperated into segments. The segment containing the code is called the code segment, and it's segment register is named CS. It's offset register is named IP or instruction pointer.
This information should be added in a page on instruction pointer and a disambiguation page should be made.
-- Bernard François 11:39, 6 March 2006 (UTC)
This is horribly unencyclopaedic in its tone, somewhere in-between OR and a POV diatribe. I'm tempted to get rid of it, because it's not particularly informative. Any thoughts? Oli Filth( talk| contribs) 01:08, 25 April 2012 (UTC)
The article currently says
That description sounds more like the description of event-driven programming to me. How the IDE is relevant here?
It seems as irrelevant to me as pointing out that
It's technically true that people often use an IDE (and wear shoes) while doing event-driven programming, but my understanding is that people find an IDE (and shoes) just as useful for programming purely sequential paradigms, and both purely sequential and event-driven software can be written without an IDE (and without shoes). I deleted the phrase "integrated development environment", but now I wonder: Is there a special connection between IDEs and non-sequential programming that I've missed? -- DavidCary ( talk) 20:28, 2 March 2013 (UTC)
This page said
If the intent was to refer to the RPC 4000's "next instruction" field in all instructions, with branches having a "branch to" instruction if the branch test succeeds and a "next instruction" field if the test fails, or similar mechanisms in other machines such as the IBM 650, it would be best to do so explicitly, so I changed it to do so.
That mechanism isn't "equivalent" in the sense of sequentially stepping through memory locations containing instructions (except when a branch occurs), but it is "equivalent" in the sense that machines with a PC (and an implied "next instruction" address of "first memory location after the current instruction") both sequentially execute a sequence of instructions. For machines with a PC, that sequence can be thought of as an array; for machines with a "next instruction" field, it could be thought of as a linked list.
As the paragraph in question was discussing sequential execution, the "next instruction" address is "equivalent" in that it doesn't provide any escape from sequential execution; if the intent is to speak only of program counters requiring sequential execution, without anything being said one way or the other about next instruction addresses, then the entire parenthetical note (whether the version before or after my edit) should be removed.
I'm not sure it's best described as "having a PC implies sequential execution"; it's perhaps better described as "sequential execution allows the use of a PC" - it's not as if removing the transistors that store the PC value is sufficient to allow the machine to run code in parallel; it's more like dataflow etc. machines have no place for a PC. Guy Harris ( talk) 07:09, 15 April 2015 (UTC)
@ Spike-from-NH:, @ Mildsunrise::
A recent edit added the claim that "In some architectures, the PC points to the current instruction plus a processor-dependent constant."; that edit was reverted.
The claim was presumably derived from the "Saving from r15" section of this part of the ARM Developer Suite Assembler Guide, which said:
In manuals describing an instruction set, the PC/IP is probably mostly used in a description of the behavior of the idealized processor that all implementations of the instruction set provide. For example, it would be used in descriptions of instructions, e.g.:
In some instruction sets, including the one whose instructions are described there, when an instruction is executed, the PC/IP points to the instruction following the one being executed, so that 1) the address of that instruction is saved as the return address and 2) when the instruction finishes, the next instruction is fetched from the PC/IP, meaning that the jump instructions cause the next instruction to be fetched from the effective address of the jump instruction. The current x86 manuals seem to show the IP/EIP/RIP working that way, as, with RIP-relative addressing, "An effective address is formed by adding displacement to the 64-bit RIP of the next instruction.", and in the description of the CALL instruction, one step is "Push(IP);", "Push(EIP);", or "Push(RIP);", pushing the address of the next instruction onto the stack.
For others, such as MIPS32, it points to the instruction being executed, so that, to quote the MIPS32 manual:
and, in the description of the Jump and Link instruction, the first step of the sequence of steps is
(+8 = +4+4, with the first +4 skipping over the JAL instruction and the second +4 skipping over the instruction in the delay slot).
The instruction set might make it visible as a general-purpose register; A32 (32-bit ARM), for example makes it visible as r15. What the ARMv7 A-profile manual says is:
So, for 32-bit ARM (the 32-bit instruction set containing ARM instructions), the PC points to the instruction following the next instruction, as instructions are all 4 bytes long. I'm not sure what the case is for Thumb/Thumb-2, as there are both 16-bit and 32-bit instructions. The Branch and Link instruction sets the link register (r14) to PC - 4, backing it up to point to the instruction following the BL instruction.
So, at the instruction set architecture level, while an instruction is being executed, the PC/IP might point to the instruction being executed, to the instruction following the instruction being executed, or somewhere else following the instruction being executed.
At the microarchitecture level, there might not be a set of N transistors that make up "the program counter register" or "the instruction pointer register"; each instruction being executed might, for example, have, associated with it, a PC/IP value appropriate to that instruction, following the rules of the instruction set architecture, and the instruction fetch hardware might have its own register holding the PC/IP value, which it copies into the stuff it hands to the execution hardware.
So the page should perhaps distinguish between "PC/IP as a concept in the description of the instruction set architecture" and its implementation in various microarchitectures. The "Hardware implementation" should discuss only the latter of the two - and not make any claims without reliable sources. That might reduce the contents of that section substantially if the references can't be found, and expand the contents substantially if they can be found. :-) The rest of the article should probably focus on the instruction set architecture PC/IP, and just indicate that it might, during the execution of an instruction, point to the instruction being executed, the next instruction that would be executed if the instruction doesn't cause a transfer of control (or even if it does cause a transfer of control if there's a branch delay slot), or some arbitrary instruction set architecture-defined or implementation-defined place past the instruction being executed. — Preceding unsigned comment added by Guy Harris ( talk • contribs)
The Symbol section mostly described symbols used in expressions evaluated by the assembler at assembly time to refer to the address of the current instruction, i.e. the value the program counter would have when the fetch of the instruction in question begins. That strikes me as more relevant to assembly language than to this page. One term used for the address of the current instruction is the "location counter"; see, for example, page 3 of the PDP-7 assembler manual, page 3-8 of the PAL III Symbolic Assembler Programming Manual for the PDP-8, page 3-13 of the PDP-11 MACRO-11 Language Reference Manual, page 3-18 of the VAX-11 MACRO Language Reference Manual, and pages 18-19 of the IBM Operating System/360 Assembler Language manual. It's called the "location assignment counter" for the 1130; see pages 7-8 of the IBM 1130 Assembler Language manual.
The bit about DEC describes, instead, a symbol used to refer to the program counter as an operand fetched (or stored into) by an instruction at run time, for those instruction sets that support this such as the PDP-11 and VAX instruction sets. DEC generally uses .
as the symbol for the address of the instruction; see, for example, page 10 of the PDP-7 assembler manual, page 3-8 of the PAL III manual, page 3-13 of the MACRO-11 manual, and page 3-18 of the VAX MACRO manual. The use of .
is more relevant to
assembly language, juast as for other symbols; the use of PC
in operands may be relevant to this page, with a discussion of those instruction sets where the PC can be used in operand specifiers.
IBM tended to use "*" as the symbol. See, for example, pages 4-5 of
the IBM 7090/7094 Programming Systems FORTRAN II Assembly Program (FAP) manual (where they don't seem to have a phrase such as "location counter", although, according to page 25, the pseudo-operation to set the counter is LOC
), pages 18-19 of the OS/360 assembler manual, and pages 9-10 of the 1130 assembler manual.
As for *-*
, that's a convention used by programmers in various IBM assembler languages to indicate to human readers of the code a value that would be set at run time; see, for example, page 5 of the IBM FAP manual. The two *
s in the expression refer to the "location counter" value; it may just be that it's a visually-notable pre-defined symbol such that subtracting it from itself 1) produces a result of 0 to use as a placeholder and 2) looks visually distinct - it may not be significant that what you're subtracting from itself is the location counter. That's a convention possibly worthy of note, but more relevant either to the
assembly language page or to the pages about the computers where that convention was used.
Guy Harris (
talk) 23:30, 8 September 2023 (UTC)
Has the PC got other uses than direct control flow? Theoretically it could:
Musaran ( talk) 06:23, 25 December 2023 (UTC)
![]() | This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||
|
This thing doesn't count programs. It counts instructions.
Wait, it doesn't count either. It jumps around in response to various events and instructions. IA-32 examples: call, ret, int, syscall, sysenter, sysret, iret...
So it's not a counter. It's a pointer.
Well gee. That must be why Intel called it the instruction pointer in their documentation.
OK, never mind the most popular CPU architecture. What about the Mac or Xbox/360? There we have the next instruction pointer register, and current instruction pointer as a concept in the documentation.
24.110.60.225 00:46, 1 January 2006 (UTC)
I have been reading a bit in my course book about computer hardware and found the following information:
8086/8088 processors have a 16 bit data bus and a 20 bit address bus, so two registers are needed to contain an address: a segment register and an offset register. The memory address can be obtained by bit-shifting the segment register by four bits to the left and performing a summation with the offset register. The memory a program used is seperated into segments. The segment containing the code is called the code segment, and it's segment register is named CS. It's offset register is named IP or instruction pointer.
This information should be added in a page on instruction pointer and a disambiguation page should be made.
-- Bernard François 11:39, 6 March 2006 (UTC)
This is horribly unencyclopaedic in its tone, somewhere in-between OR and a POV diatribe. I'm tempted to get rid of it, because it's not particularly informative. Any thoughts? Oli Filth( talk| contribs) 01:08, 25 April 2012 (UTC)
The article currently says
That description sounds more like the description of event-driven programming to me. How the IDE is relevant here?
It seems as irrelevant to me as pointing out that
It's technically true that people often use an IDE (and wear shoes) while doing event-driven programming, but my understanding is that people find an IDE (and shoes) just as useful for programming purely sequential paradigms, and both purely sequential and event-driven software can be written without an IDE (and without shoes). I deleted the phrase "integrated development environment", but now I wonder: Is there a special connection between IDEs and non-sequential programming that I've missed? -- DavidCary ( talk) 20:28, 2 March 2013 (UTC)
This page said
If the intent was to refer to the RPC 4000's "next instruction" field in all instructions, with branches having a "branch to" instruction if the branch test succeeds and a "next instruction" field if the test fails, or similar mechanisms in other machines such as the IBM 650, it would be best to do so explicitly, so I changed it to do so.
That mechanism isn't "equivalent" in the sense of sequentially stepping through memory locations containing instructions (except when a branch occurs), but it is "equivalent" in the sense that machines with a PC (and an implied "next instruction" address of "first memory location after the current instruction") both sequentially execute a sequence of instructions. For machines with a PC, that sequence can be thought of as an array; for machines with a "next instruction" field, it could be thought of as a linked list.
As the paragraph in question was discussing sequential execution, the "next instruction" address is "equivalent" in that it doesn't provide any escape from sequential execution; if the intent is to speak only of program counters requiring sequential execution, without anything being said one way or the other about next instruction addresses, then the entire parenthetical note (whether the version before or after my edit) should be removed.
I'm not sure it's best described as "having a PC implies sequential execution"; it's perhaps better described as "sequential execution allows the use of a PC" - it's not as if removing the transistors that store the PC value is sufficient to allow the machine to run code in parallel; it's more like dataflow etc. machines have no place for a PC. Guy Harris ( talk) 07:09, 15 April 2015 (UTC)
@ Spike-from-NH:, @ Mildsunrise::
A recent edit added the claim that "In some architectures, the PC points to the current instruction plus a processor-dependent constant."; that edit was reverted.
The claim was presumably derived from the "Saving from r15" section of this part of the ARM Developer Suite Assembler Guide, which said:
In manuals describing an instruction set, the PC/IP is probably mostly used in a description of the behavior of the idealized processor that all implementations of the instruction set provide. For example, it would be used in descriptions of instructions, e.g.:
In some instruction sets, including the one whose instructions are described there, when an instruction is executed, the PC/IP points to the instruction following the one being executed, so that 1) the address of that instruction is saved as the return address and 2) when the instruction finishes, the next instruction is fetched from the PC/IP, meaning that the jump instructions cause the next instruction to be fetched from the effective address of the jump instruction. The current x86 manuals seem to show the IP/EIP/RIP working that way, as, with RIP-relative addressing, "An effective address is formed by adding displacement to the 64-bit RIP of the next instruction.", and in the description of the CALL instruction, one step is "Push(IP);", "Push(EIP);", or "Push(RIP);", pushing the address of the next instruction onto the stack.
For others, such as MIPS32, it points to the instruction being executed, so that, to quote the MIPS32 manual:
and, in the description of the Jump and Link instruction, the first step of the sequence of steps is
(+8 = +4+4, with the first +4 skipping over the JAL instruction and the second +4 skipping over the instruction in the delay slot).
The instruction set might make it visible as a general-purpose register; A32 (32-bit ARM), for example makes it visible as r15. What the ARMv7 A-profile manual says is:
So, for 32-bit ARM (the 32-bit instruction set containing ARM instructions), the PC points to the instruction following the next instruction, as instructions are all 4 bytes long. I'm not sure what the case is for Thumb/Thumb-2, as there are both 16-bit and 32-bit instructions. The Branch and Link instruction sets the link register (r14) to PC - 4, backing it up to point to the instruction following the BL instruction.
So, at the instruction set architecture level, while an instruction is being executed, the PC/IP might point to the instruction being executed, to the instruction following the instruction being executed, or somewhere else following the instruction being executed.
At the microarchitecture level, there might not be a set of N transistors that make up "the program counter register" or "the instruction pointer register"; each instruction being executed might, for example, have, associated with it, a PC/IP value appropriate to that instruction, following the rules of the instruction set architecture, and the instruction fetch hardware might have its own register holding the PC/IP value, which it copies into the stuff it hands to the execution hardware.
So the page should perhaps distinguish between "PC/IP as a concept in the description of the instruction set architecture" and its implementation in various microarchitectures. The "Hardware implementation" should discuss only the latter of the two - and not make any claims without reliable sources. That might reduce the contents of that section substantially if the references can't be found, and expand the contents substantially if they can be found. :-) The rest of the article should probably focus on the instruction set architecture PC/IP, and just indicate that it might, during the execution of an instruction, point to the instruction being executed, the next instruction that would be executed if the instruction doesn't cause a transfer of control (or even if it does cause a transfer of control if there's a branch delay slot), or some arbitrary instruction set architecture-defined or implementation-defined place past the instruction being executed. — Preceding unsigned comment added by Guy Harris ( talk • contribs)
The Symbol section mostly described symbols used in expressions evaluated by the assembler at assembly time to refer to the address of the current instruction, i.e. the value the program counter would have when the fetch of the instruction in question begins. That strikes me as more relevant to assembly language than to this page. One term used for the address of the current instruction is the "location counter"; see, for example, page 3 of the PDP-7 assembler manual, page 3-8 of the PAL III Symbolic Assembler Programming Manual for the PDP-8, page 3-13 of the PDP-11 MACRO-11 Language Reference Manual, page 3-18 of the VAX-11 MACRO Language Reference Manual, and pages 18-19 of the IBM Operating System/360 Assembler Language manual. It's called the "location assignment counter" for the 1130; see pages 7-8 of the IBM 1130 Assembler Language manual.
The bit about DEC describes, instead, a symbol used to refer to the program counter as an operand fetched (or stored into) by an instruction at run time, for those instruction sets that support this such as the PDP-11 and VAX instruction sets. DEC generally uses .
as the symbol for the address of the instruction; see, for example, page 10 of the PDP-7 assembler manual, page 3-8 of the PAL III manual, page 3-13 of the MACRO-11 manual, and page 3-18 of the VAX MACRO manual. The use of .
is more relevant to
assembly language, juast as for other symbols; the use of PC
in operands may be relevant to this page, with a discussion of those instruction sets where the PC can be used in operand specifiers.
IBM tended to use "*" as the symbol. See, for example, pages 4-5 of
the IBM 7090/7094 Programming Systems FORTRAN II Assembly Program (FAP) manual (where they don't seem to have a phrase such as "location counter", although, according to page 25, the pseudo-operation to set the counter is LOC
), pages 18-19 of the OS/360 assembler manual, and pages 9-10 of the 1130 assembler manual.
As for *-*
, that's a convention used by programmers in various IBM assembler languages to indicate to human readers of the code a value that would be set at run time; see, for example, page 5 of the IBM FAP manual. The two *
s in the expression refer to the "location counter" value; it may just be that it's a visually-notable pre-defined symbol such that subtracting it from itself 1) produces a result of 0 to use as a placeholder and 2) looks visually distinct - it may not be significant that what you're subtracting from itself is the location counter. That's a convention possibly worthy of note, but more relevant either to the
assembly language page or to the pages about the computers where that convention was used.
Guy Harris (
talk) 23:30, 8 September 2023 (UTC)
Has the PC got other uses than direct control flow? Theoretically it could:
Musaran ( talk) 06:23, 25 December 2023 (UTC)