Prefetch input queue

Most modern processors load their instructions before they execute them. Due to this, a change in the processor code immediately in front of the current location of execution might not change how the processor interpretent the code, as it is allready loaded into it's Prefetch Input Queue (PIQ). It simply executes it's old copy already loaded in the PIQ instead of the new and alterd version of the code in it's RAM and/or cache.

This behaviour only applies to von neuman computers (that is, not harward-computers) and computers that can run self-modifying code.

What to use the PIQ to

When the x86-processor changes mode from realmode to protected mode and vice versa, the PIQ has to be flushed, or else the CPU will continiue to translate the mashinecode as if it was written in it's last mode. If the PIQ is not flushed, the processor might translate it's codes wrong and generate an invalid instruction interrupt.

The PIQ could also be used to determine if code is being executed inside a emulator or in a authentic computer. Most emulators will probably never simulate this quiet oddly behaviour. If the PIQ-size is zero (changes in the code affect allways affect the state of the processor), it is quiet certain that the code is being executed in an emulator.

x86 example code

   mov [ahead], 0x9090     ; 0x9090 = two NO oPeration (0x90 = "nop")

ahead: 
   jmp to_the_end          ; jmp to_the_end is two bytes of mashinecode
   ; this code should never execute in a real processor, but it does.

to_the_end:
   ; this code only executes in computers with zero-lenght PIQ (inside emulators)

This self-modifying code overwrites the jump with "do-nothing", but because the jump is allready read into the PIQ, it executes even tho it does not really exist anymore.