Talk:Prefetch input queue

Text and/or other creative content from this version of Queueing model was copied or moved into Prefetch input queue with this edit. The former page's history now serves to provide attribution for that content in the latter page, and it must not be deleted as long as the latter page exists.

Unknown subject

I think you should add some more details regarding 8086 architecture.

Ajinkya.domale (talk)

Von Neumann vs. Harvard

Can anyone clarify why these should make a difference to the practicality of a prefetch queue? Thanks

Recent work to this article looks pretty good. Thanks to everyone who contributed Andy Dingley (talk) 19:55, 30 October 2011 (UTC)[reply]

Look out for possible copyright violations in this article

This article has been found to be edited by students of the Wikipedia:India Education Program project as part of their (still ongoing) course-work. Unfortunately, many of the edits in this program so far have been identified as plain copy-jobs from books and online resources and therefore had to be reverted. See the India Education Program talk page for details. In order to maintain the WP standards and policies, let's all have a careful eye on this and other related articles to ensure that no material violating copyrights remains in here. --Matthiaspaul (talk) 12:53, 31 October 2011 (UTC)[reply]

Merger proposal

I propose that Instruction prefetch be merged into Prefetch input queue. altmany (talk) 22:48, 16 March 2013 (UTC)[reply]

I don't think that this would be a good idea. "Instruction prefetch" is (from my viewpoint) a completely different topic than the "Prefetch input queue". Yes, I do agree that the "Instruction prefetch" article is a stub and is small, but merging it with an article about the PIQ would not make sense. Please don't merge the articles. 70.114.174.122 (talk) 01:28, 15 April 2015 (UTC)[reply]

Example program to detect size

I tested the proposed program on an AT compatible 80286 (IBM PS/1 model 2011) in real mode, and the result was 4 bytes, which is wrong because the i286 has a 6 bytes prefetch queue. Knowing the pipelined nature of the 286, and considering that the AT is a 1 wait state architecture (3 cycles per read), I think the code will never work as intended. The reason is pretty clear once you also consider the MOV size (5 bytes), its execution time (3 cycles), the NOP size (1 byte), and the fact that the MOV (on my program) is on an odd address. Also, as has already been noted in the article, if the code is being executed under a multitasking OS, the context switch may lead to a wrong value. For these reasons I propose to remove it. Barotto (talk) 13:45, 9 May 2015 (UTC)[reply]

India Education Program course assignment

This article was the subject of an educational assignment at Department of Electronics and Telecommunication, College of Engineering, Pune, India supported by Wikipedia Ambassadors through the India Education Program during the 2011 Q3 term. Further details are available on the course page.

The above message was substituted from {{IEP assignment}} by PrimeBOT (talk) on 20:15, 1 February 2023 (UTC)[reply]

Self-modifying code restriction

Regarding the following text in the article:

When executing self-modifying code, a change in the processor code immediately in front of the current location of execution might not change how the processor interprets the code, as it is already loaded into its PIQ. It simply executes its old copy already loaded in the PIQ instead of the new and altered version of the code in its RAM and/or cache.

Is there a citation or source for this that explains where and when this can actually occur? Is this behavior a documented part of the x86 programming model? I would be curious to learn more about this, and whether this is purely a theoretical concern/possibility or whether this behavior actually exists on any modern processors. Erik K Swan (talk) 21:18, 28 April 2023 (UTC)[reply]

I found some extensive discussion on this question here, here, here, and here.

It seems like the conclusion is that this behavior did exist on old Intel processors, but modern x86 processors (likely anything newer than Pentium Pro) will detect the write and flush the instruction prefetch queue/pipeline, and they will never execute stale instructions, even if an instruction modifies the very next instruction. However, the cost of this is very large and performance will be very poor.

It's not clear how other modern processors with different ISAs (e.g. AArch64) behave. Erik K Swan (talk) 19:06, 30 April 2023 (UTC)[reply]