Editing Prefetch input queue (section)

==Introduction==

[[Pipeline (computing)|Pipelining]] was brought to the forefront of computing architecture design during the 1960s due to the need for faster and more efficient computing. Pipelining is the broader concept and most modern processors load their instructions some [[clock cycle]]s before they execute them. This is achieved by pre-loading [[machine code]] from memory into a  ''prefetch input queue''.

This behavior{{clarify|date=June 2020 |reason=Unclear what behavior is being referenced. I think a previous revision referred to modification of instructions in the queue, but now this paragraph doesn't make sense.}} only applies to [[von Neumann computer]]s (that is, not [[Harvard architecture]] computers) that can run [[self-modifying code]] and have some sort of [[instruction pipelining]]. Nearly all modern high-performance computers fulfill these three requirements.<ref>{{cite web|title=ARM Information Center|url=http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka3839.html|work=ARM Technical Support Knowledge Articles}}</ref>

Usually, the prefetching behavior of the PIQ is invisible to the [[programming model]] of the CPU. However, there are some circumstances where the behavior of PIQ is visible, and needs to be taken into account by the programmer.

When an [[x86]] processor changes mode from [[real mode]] to [[protected mode]] and vice versa, the PIQ has to be flushed, or else the CPU will continue to translate the [[machine code]] as if it were written in its last mode. If the PIQ is not flushed, the processor might translate its codes wrong and generate an invalid instruction [[Exception handling|exception]].

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 [[random access memory|RAM]] and/or [[CPU cache|cache]].

This behavior of the PIQ can be used to determine if code is being executed inside an [[emulator]] or directly on the hardware of a real CPU.{{fact|date=May 2013}} Most emulators will ''probably'' never simulate this behavior. If the PIQ-size is zero (changes in the code ''always'' affect the state of the processor immediately), it can be deduced that either the code is being executed in an emulator or the processor invalidates the PIQ upon writes to addresses loaded in the PIQ.