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

Date:December 8, 2003 / year-entry #154
Tags:history
Orig Link:https://blogs.msdn.microsoft.com/oldnewthing/20031208-00/?p=41583
Comments:    7
Summary:If you look at the implementation of FlushInstructionCache on Windows 95, you'll see that it's just a return instruction. It doesn't actually do anything. So why do you have to call it? Because the act of calling it is the whole point. The control transfers implicit in calling a function suffice to flush the instruction...

If you look at the implementation of FlushInstructionCache on Windows 95, you'll see that it's just a return instruction. It doesn't actually do anything. So why do you have to call it?

Because the act of calling it is the whole point. The control transfers implicit in calling a function suffice to flush the instruction cache on a Pentium. The function doesn't have to do anything else; it is fact that you called a function that is important.


Comments (7)
  1. Florian says:

    I suppose the implementation of that function is hidden in some library and is made staying there by shaking a large stick at it. (As you may be able to tell I have no clue about Windows programming.)
    Because normally such an empty function would be optimized away by any half-decent compiler, wouldn’t it?
    Actually what I was wondering about was how to look at the implementation without being employed by MS.

  2. Anonymous says:

    FlushInstructionCache is in kernel32.dll I think. No way the C++ compiler/linker can optimize a function it doesn’t know about till run time. Just step into the function in the debugger but then you only get the assembly listing or you can join a college/company that gets access to the windows source code (I’d imagine it’s not cheap).

  3. Jordan Russell says:

    So the documentation is inaccurate, then?

    "Windows Me/98/95: The FlushInstructionCache function has no effect"

  4. phaeron says:

    Are you sure you’re not thinking of the prefetch queue, Raymond? Control transfers were needed to flush the prefetch queue on CPUs up to the 486, which is why "jmp short $+2" was used after self-modifying code… but the Pentium was the first CPU to not require this. I would hope that the CPU wouldn’t flush the cache on a simple indirect call!

    I thought the reason for FlushInstructionCache() was for the NT kernel to execute inter-processor interrupts to ensure that all CPUs in a system saw code changes (cross-modifying code), which would mean that it isn’t required in Win95/98 since those OSes don’t support SMP.

  5. Raymond Chen says:

    Hm, maybe you’re right on the prefetch. I must be getting my processors confused. I know that some processor somewhere required a jump to flush the prefetch, I assumed it applied to the Pentium as well, but perhaps not.

  6. Mark Hurd says:

    Sounds similar to the .NET GC.KeepAlive() routine that doesn’t do anything, but just calling it stops its argument from being seen by the compiler as ready for garbage collection.

  7. Because it’s the fact that you cared.

Comments are closed.


*DISCLAIMER: I DO NOT OWN THIS CONTENT. If you are the owner and would like it removed, please contact me. The content herein is an archived reproduction of entries from Raymond Chen's "Old New Thing" Blog (most recent link is here). It may have slight formatting modifications for consistency and to improve readability.

WHY DID I DUPLICATE THIS CONTENT HERE? Let me first say this site has never had anything to sell and has never shown ads of any kind. I have nothing monetarily to gain by duplicating content here. Because I had made my own local copy of this content throughout the years, for ease of using tools like grep, I decided to put it online after I discovered some of the original content previously and publicly available, had disappeared approximately early to mid 2019. At the same time, I present the content in an easily accessible theme-agnostic way.

The information provided by Raymond's blog is, for all practical purposes, more authoritative on Windows Development than Microsoft's own MSDN documentation and should be considered supplemental reading to that documentation. The wealth of missing details provided by this blog that Microsoft could not or did not document about Windows over the years is vital enough, many would agree an online "backup" of these details is a necessary endeavor. Specifics include:

<-- Back to Old New Thing Archive Index