Talk:Program counter

From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Computing / Hardware (Rated C-class, Low-importance)
WikiProject icon This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
C-Class article C  This article has been rated as C-Class on the project's quality scale.
 Low  This article has been rated as Low-importance on the project's importance scale.
Taskforce icon
This article is supported by Computer hardware task force (marked as Low-importance).

"program counter" is a non-standard misnomer[edit]

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. 00:46, 1 January 2006 (UTC)

Yes, it counts :-)
The vast majority of instruction fetches are from the next memory location after the previously fetched instruction.
Random-access jumps or branches to other locations are relatively infrequent by comparison.
The PC is a pointer, true, and also a counter
TheAMmollusc (talk) 11:47, 20 October 2008 (UTC)
Von Neumann himself used the term "Program Counter." I think "Instruction Pointer" is a non-standard misnomer. Whenever I see "IP" in a computer-related context I think of "Internet Protocol" (specifically the "IP address") or "Intellectual Property" before I think of Intel's non-standard misnomer. When I see "PC" in a computer-related context I think of "Personal Computer" and then "Program Counter." "EIP" looks like a sound someone makes when they step on something sharp or slimy, and "RIP" means I'll soon be able to say "RIP" to the x86 that only exists today because of the Datapoint 2200, IBM and Microsoft. I just can't wait for Ivy Bridge: I'd be able to boot DOS twice as fast! — "Windows n. (Win-doze): A 64 bit tweak of a 32 bit extension to a 16 bit user interface for an 8 bit operating system based on a 4 bit architecture from a 2 bit company that can't stand 1 bit of competition." (talk) 05:26, 26 February 2011 (UTC)
Hey, there's a lot of truth to that. You got me laughing as hard as I have at any joke told on TV at 11:30pm in a long time, thanks. Seems like a perfect example of Not Invented Here syndrome. Trouble is, oftentimes the we set the standards crowd uses superior business strategy to make their version better known and more widely adopted than the inventor's, leaving it up to neutral Wikipedia editors to sort through the confusion. I'll update the article to provide some references and clarify things for people like the student below. Wbm1058 (talk) 20:25, 21 October 2011 (UTC)
Page 1-5 (PDF page 16) of the Intel iAPX88 Book] says Figure 1-9 shows two 16-bit control registers. First is the IP or instruction pointer which points to the next instruction the bus interface unit will fetch. (The instruction pointer is similar to a Program Counter used in other microprocessors, except that the IP points to the next instruction being fetched, whereas the traditional program counter points to the next instruction to be executed). Intel themselves used the term Program Counter in their 8008 and 8080 processors. BTW, PowerPC calls it a Next Instruction Address Register which is a much better term because "Instruction Pointer" can refer to anything holding an instruction address! — Preceding unsigned comment added by (talk) 05:10, 17 September 2012 (UTC)

instruction pointer disambiguation[edit]

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)

No, no, please don't. We don't need a content fork. PC and IP are truly two different terms for the same fundamental concept. If you understand this you should LOL at the joke in the above section. This is a related discussion so I'm making it a subtopic under the above. Wbm1058 (talk) 20:25, 21 October 2011 (UTC)

POV section: "All-pervasive nature of the program counter"[edit]

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)

I thought my version was a vast improvement in terms of this exact problem. In particular, it went from exploring the state-of-mind of the programmer, to merely discussing the implications of the sequential-execution model. I do not see why you reverted to the previous version to attach {{POV}}. Spike-from-NH (talk) 01:43, 25 April 2012 (UTC)
Oh, that was completely unintentional, I have no idea how that occurred. Reverted now. Oli Filth(talk|contribs) 13:17, 25 April 2012 (UTC)
Whew! Thank you for the clarification. Spike-from-NH (talk) 17:39, 25 April 2012 (UTC)

integrated development environment[edit]

The article currently says

  • "In an integrated development environment, the programmer may write sequences of instructions to respond to events without specifying an overall sequence for the program."

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

  • "While wearing shoes, the programmer may write sequences of instructions to respond to events without specifying an overall sequence for the program."

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)

There is not. The two concepts go together in my limited experience programming after text editors, but your edit makes it more precise.
Regarding the paragraph you added afterward, you need an initial "In" at least for parallelism. And your three links seem inter-related. As your text says they go from the specific to the general, you should pick the one whose generality aligns most closely with "writ[ing] each section of the pipeline without specifying the timing relative to other sections." Spike-from-NH (talk) 02:25, 3 March 2013 (UTC)

IBM 650-style "next instruction field" as a PC equivalent[edit]

This page said

Use of a PC that normally increments assumes that what a computer does is execute a usually linear sequence of instructions. Such a PC (or equivalent hardware that serves the same purpose[8]) is central to the von Neumann architecture. Thus programmers write a sequential control flow even for algorithms that do not have to be sequential.
with reference 8 pointing to The story of Mel - an entertaining story, but really not much of a reference.

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)

Yes; I had challenged your edit on your talk page. Your point is made that PCs don't "imply sequential execution" (and the article goes on to describe alternative concepts in the following section). And I too found "A story of Mel" interesting but not relevant to this discussion.
The section in question discusses what computers "typically" do and how that led to problems, more research, and different architectures. Atypical examples did not lead to any of the above. The word "typically" implies there are counterexamples; regarding listing them, it's unlikely that a reader would come to Program counter to read about computers that didn't use program counters, but if you think so, that should be a separate discussion in the article. At least, the parenthetical remark should be removed. Spike-from-NH (talk) 12:47, 15 April 2015 (UTC)
Hearing no objection, I removed the remark. Spike-from-NH (talk) 12:50, 21 April 2015 (UTC)