If FlushInstructionCache doesn’t do anything, why do you have to call it, revisited
You are supposed to call the
FlushInstructionCache function when you generate or modify code at runtime, so that when the CPU tries to execute the newly-generated or newly-modified modified code, it will read the instructions you wrote, rather than any instructions that may be hanging around in the instruction cache.
Some time ago, we saw that on Windows 95, the
FlushInstructionCache function didn’t do anything aside from returning. That’s because the mere act of calling a function was sufficient to flush the instruction cache.
On Windows NT, however, the
FlushInstructionCache function does actual work, since it needs to notify all the other processors of the need to flush their instruction caches, too.
But if you look at Windows 10, you may find that the
FlushInstructionCache function looks like the Windows 95 version: It doesn’t do anything.
What’s going on?
FlushInstructionCache function “does anything” depends on which processor you’re using. Some processors have an integrated data and instruction cache, in which case the
FlushInstructionCache function doesn’t need to do anything. Others such as ARM still have separate instruction and data caches, and in those cases, flushing does real work. Whether the
FlushInstructionCache function “does anything” depends on the processor architecture it was compiled for.
As a programmer, you should just call the
FlushInstructionCache function and let the operating system figure out whether flushing will actually need to “do anything”.
Why did Windows 95 flush the instruction cache for every function call? That must be a big performance killer.
The people you need to ask that are at Intel. As Raymond said in the linked article, it wasn’t Windows manually doing the flushing, but the Pentium processor, automatically.
I think he probably meant calling a function invalidates the prefetch queue. This would force the processor to reload any pre-loaded instructions that may have been modified.