Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!swrinde!ucsd!helios.ee.lbl.gov!lbl.gov!jnmoyne
From: jnmoyne@lbl.gov (Jean-Noel MOYNE)
Newsgroups: comp.sys.amiga
Subject: Re: Whats wrong with self Modifying Code?
Message-ID: <6171@helios.ee.lbl.gov>
Date: 12 Jul 90 21:45:03 GMT
References: <24379@snow-white.udel.EDU>
Sender: usenet@helios.ee.lbl.gov
Organization: Lawrence Berkeley Laboratory
Lines: 21
X-Local-Date: 12 Jul 90 14:45:03 PDT


       The problem with self modifying code, is that if your system has 
got a cache memory for the instructions, modifying code (in memory) that 
is still in the cache won't modify code in the cache, and the CPU will 
still execute the unmodified code in its cache.

       So, to run such software on 020s and 030s, you have to turn the 
cache off for the instructions (not likely to increase the speed, and 
since you're looking for speed). And since you canot make assumptions on 
what is on the cache at a specified moment, the rules are: don't make any 
selfmodifying code. Sure if you modifiy code which is 512Ko away of the 
actual PC position, you can think that it's not in the cache, but you're 
still making suppositions ...

     Anyway you can allways write non selfmodifying code which is fast 
enough, especially on a 68000 (or a 68020 or more) for all sort of speedy 
applications. Self modifying code could be usefull on 8 bits CPU, but if 
you search a little more you can live without it on the Amiga>


   JNM