• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

self modifying executables

C

CTho9305

Elite Member
how does a harvard architecture handle self-modifying code? i've always been told the writing has to take place in the data cache, and the instruction cache marked invalid. how is it implemented?
 
most likely it gives you a protection fault.
I don't think many executeables do this anymore. They used to because of the lack of available memory.
The OS should forbid doing this.

I think you can do this with explicit software calls to flush the cache. This is likely what current architectures are like.
You can also try to see if you hit in the i cache and flush it if you write back. I doubt any do this because of the extreme rarity of the code, and it would increase cache access time.
 
The instruction cache is invalidated when you write to the corresponding memory region that the instruction lives in. On modern processors this causes the processor to fault, invalidate/flush the cache, write out the datacache line (the one that contains the instruction), dump all instructions which are currently in flight, and reload everything from step 1. Also any predecode (or similar) bits are tossed.. and if you do it on a P4, you may as well turn the trace cache off 😉

Oh yeah and I would LOVE to see this code run on a transmeta CPU.. I bet it really makes a mess of code-morphing 😉

Steve
 
You must log in or register to reply here.

TRENDING THREADS

Back
Top