If FlushInstructionCache doesn’t do anything, why do you have to call it, revisited

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”.

The post If FlushInstructionCache doesn’t do anything, why do you have to call it, revisited appeared first on The Old New Thing.