You are supposed to call the FlushÂInstructionÂCache 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 FlushÂInstructionÂCache 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 FlushÂInstructionÂCache 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 FlushÂInstructionÂCache function looks like the Windows 95 version: It doesn’t do anything.
What’s going on?
Whether the FlushÂInstructionÂCache function “does anything” depends on which processor you’re using. Some processors have an integrated data and instruction cache, in which case the FlushÂInstructionÂCache 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 FlushÂInstructionÂCache function “does anything” depends on the processor architecture it was compiled for.
As a programmer, you should just call the FlushÂInstructionÂCache 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.
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.
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.