Self-modifying code

Allen J. Baum baum at Apple.COM
Wed Jul 13 05:42:38 AEST 1988


[]
>In article <5262 at june.cs.washington.edu> pardo at uw-june.UUCP (David Keppel) writes:
>
>There is a *major* problem with modifying existing code.  Consider a
>machine with seperate I-cache and D-cache.  If you execute an
>instruction at location 0x500, then one at 0x504 that branches back
>to the one at 0x500, and the one at 0x500 modifies itself, either:
>
>  + The cache can be built so that it pays attention to the changing
>    data (code) in the I-cache....
>  + You can execute out of the D-cache....
>  + You can define this operation to be illegal....

or you can recognize the situation and issue a write-back-Dcache-line
instruction, and a flush-Icache-line instruction, and everything works.
Note that a compile-and-go situation is exactly this; you are building
a program in the Dcache, and then you want to execute it. While it may
be unlikely that any remnants are left over after linking, et. al., this
may be the only way to guarantee it.

--
{decwrl,hplabs,ihnp4}!nsc!apple!baum		(408)973-3385



More information about the Comp.lang.c mailing list