Xref: utzoo comp.lang.c:11299 comp.arch:5461
Path: utzoo!attcan!uunet!husc6!mailrus!ames!amdahl!apple!baum
From: baum@Apple.COM (Allen J. Baum)
Newsgroups: comp.lang.c,comp.arch
Subject: Re: Self-modifying code
Message-ID: <13805@apple.Apple.COM>
Date: 12 Jul 88 19:42:38 GMT
References: <3353@cognos.UUCP> <619@goofy.megatest.UUCP> <429@uwovax.uwo.ca> <5254@june.cs.washington.edu> <12357@ut-sally.UUCP> <5262@june.cs.washington.edu>
Reply-To: baum@apple.UUCP (Allen Baum)
Organization: Apple Computer, Inc.
Lines: 21

[]
>In article <5262@june.cs.washington.edu> pardo@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