Do anyone know how to FlushInstructionCache. What i did below do not work i don't think. Also here is what the API Help file say: [ Thanks in advance ]

BOOL FlushInstructionCache(

HANDLE hProcess, // handle of process with cache to flush
LPCVOID lpBaseAddress, // address of region to flush
DWORD dwSize // length of region to flush


PUSH 22 .................................. Size of this buffer
PUSH offset BUFFER_1............ Name of The buffer previous used
PUSH h_This_Handle................ Handle to my own process
CALL FlushInstructionCache..... Now i want to flush it all out of the cache since it is still in the system/processor/cache or where ever


My Beef with this:
This is really kind of stupid to me because if we already ran the instruction in pure ASM i don't look for the system to hold anything becauseeeee if want to do it again with pure Assembly I DON'T need no *cache* HELP, so I don't care about the pro's, con's and suspects... i want it out there and that IT.

Thank you
Posted on 2002-12-24 15:40:31 by cmax
By the way i did a search on the board and there is NOTHING about FlushInstructionCache no where to be founded. Must be a hard thing to do.
Posted on 2002-12-24 16:38:09 by cmax

Hi cmax,
IIRC FlushInstructionCache is supported only on NT and derivates because in Microsoft's view it's useful only for multiprocessor systems anyway (which aren't supported on 9x).

If you do self modifying code you don't need to call FlushInstructionCache anyway, because SMC and related pipeline/cache/memory coherence is supported by the hardware anyway.

Are you experimenting on a 9x OS?
Posted on 2002-12-24 17:18:44 by Maverick
"Are you experimenting on a 9x OS"

Hello Maverick

Yes i am, it's the only one i got, but by design because i want to make my app work for all Windows Version and i will
face the new problems when i get my hands on the NT, 2000 and XP.

I am chopping my app down to size and using all that i have learned here at the Board for the past 1 1/2 years that i
have been here and it's LOOKING BETTER now and i am getting around to HOPFULLY everything that i did not understand before. But it is really getting very EASY because of the new information posted here. Now all i got to do is go back into TIME :) :) :) to add the goodies

Thanks for putting me in check about the FlushInstructionCache and i still don't really know how to do self modifying code
just yet but my goal right now is to chop most of the fat out of my project while at the same time reading previous posts so i be half ready when i get to the REAL GOOD STUFF. So i will not go into HOW TO DO THAT right now. :(

Thanks Again Maverick and Merry Xmax
Posted on 2002-12-24 18:17:21 by cmax
You could always flush the cache manually.
Works on all OS's and processors.
Flush_instruction_cache PROC icache:DWORD

mov ecx, icache
push 0FD78C3FFh
_1: push 0FC780478h ; :)
sub ecx, 4
jns _1
call esp
Flush_instruction_cache ENDP
Posted on 2002-12-24 18:48:31 by bitRAKE
wouldn't INVD do that?

INVD - Invalidate Cache (486+)
Usage: INVD
Modifies flags: none
Flushes CPU internal cache. Issues special function bus cycle
which indicates to flush external caches. Data in write-back
external caches is lost.
Posted on 2002-12-24 20:32:40 by Miko

cmax: when there are differences between 9x and NT (and indeed there are), the most straightforward and logical thing to do would be to execute different routines depending on which OS your program is running on. This either by annoying IF's all around, or by a more efficient system, like a code/data modules system (with your own object/executable format) where each module contains different versions (for different CPU's or OS's) and your loader automatically loads the right one for the host PC, saving you from the hassle and from any waste of RAM. This would give you the benefit of having (very transparently) a MMX/SSE version of the module where you would gain from it, having OS-specific versions in the modules where it's necessary to do so, later have your tight innerloops optimized for each CPU, etc..

Rakey: wow.. what a code, is it aimed at Saddam? :grin: It's an elegant idea anyway. :)

Miko: INVD is privileged (but you would want to use WBINVD anyway!).
Posted on 2002-12-25 04:08:46 by Maverick

Can explain the code? I do not understand it.
Posted on 2002-12-25 07:26:27 by roticv

It simply fills the stack (and thus the data cache) with NOP-style opcodes, and then executes it (and thus fills also the instruction cache).
The first PUSH makes sure that it will actually return.

A good example of using own's brain creatively (typical of most asm programmers), rather than opening a book and looking for a ready-made solution (typical of most (not all of course!) HLL programmers).

OOOOOOPS.. I replied in place of bitRAKE.. hope you don't mind, Ricky, I just enjoy to see such atypical code solutions. :alright:
Posted on 2002-12-25 07:34:01 by Maverick
roticv, watch the code in OllyDbg:
- set a breakpoint on CALL ESP (F2).
- single step (F7).
- single step to watch code jump around.
- move scroll bar all the way to the bottom to see return code.

The FASM version of this code would be easier to understand. I just whipped this up - it might not assemble? I'm an FASM newbie, but I really like some of the features. :)

; use stack frame so we can restore ESP value
; after variable number of PUSH's.
push ebp
mov ebp, esp

virtual at 0
db 0FFh ; anything you want
..x: retn
js ..x

load ..a from 0
end virtual

push ..a
mov ecx, [ebp+8] ; size of instruction cache in bytes

virtual at 0
..y: js ..z + 4
..z: js ..y

load ..b from 0
end virtual
push ..b
sub ecx, 4
jns more
call esp
ret 4

Maverick, thanks for explaining. :)
Posted on 2002-12-25 14:04:50 by bitRAKE
Filling with nop is perfect for me since im using 95 and it will be good enough for all versions. It was about nothing major to hide, I just want to be sure that not much is in the way when i run a certain block of code. It feels good to know that i can fill cache with only be full of zero's, along with other things i was worried about. With this added piece of code i can't blame anything if my code fail for some reason. I don't have total faith in the OS so I just wanted to add some insurence. and it's also great to know that Maverick still have never been proven wrong :) Posted on 2002-12-26 00:21:02 by cmax

:P that code was actually very straightforward and very readable, but anyway..
Posted on 2002-12-26 02:59:48 by Maverick