Path: utzoo!utgpu!news-server.csri.toronto.edu!qucdn!leek Newsgroups: comp.sys.amiga Subject: Re: Whats wrong with self Modifying Code? Organization: Queen's University at Kingston Date: Monday, 16 Jul 1990 17:47:31 EDT From: Message-ID: <90197.174731LEEK@QUCDN.BITNET> Distribution: na References: <6180@helios.ee.lbl.gov> <31727@cup.portal.com> <13203@mcdphx.phx.mcd.mot.com> <31749@cup.portal.com> In article <31749@cup.portal.com>, Sullivan@cup.portal.com (sullivan - segall) says: > >It would seem a terrible shame though to lose that capability in the 68040, >and have to clear 8k worth of cache any time a DMA completes. Yes, but that have nothing to do with self-modifying code... That's OS problem. ... stuff refering to previous article deleted.... >In the real world this isn't an acceptable practice. If I need to run >self modifying code for speed, I won't have time to make an OS call. Or >to put it differently, if I had the time to make an OS call, I wouldn't >need to use self modifying code, I could just jump to the appropriate >vector. Turning off /flushing a large cache might be a larger performance lost than just doing vector jumps. Why one would want to save a few machine cycles while at the same time trying to run the CPU at 20% - 300% slower (depending on program and CPU) is beyond my comprehension. The major speed advantage of the 020,030 etc are due to the caches. Make sure you sit down with the machine cycles for both cases (ie. cache with well behaved code and nocache with self-modifying codes) before making any assumptions. Flushing 4K worth of instruction cache in a 040 is probably bad. If the amount of time saved is justified, then go for it. You'll get better performance than turning off the cache entirely. Do the OS call as it is neglectable vs flushing the cache !! > >The only exception I can imagine, where an OS routine of this sort would >be useful, is when my program needs to compile something directly into >memory. In that case I still think it would be faster to either define >that memory segment as uncacheable, or (at least temporarily) turn off >the execution cache entirely. Read above for disadvantages of turning off cache... Might be better to use the RAM: drive. > > MEMF_ECACHE > MEMF_DCACHE > >where the default is TRUE for DCACHE , and FALSE for ECACHE. That would >tend to leave the exec() code in the cache (where IMHO it belongs) and >user programs would be cached if they specifically request it. (If you >know you are going to be using the CPU for a long time, at a higher priority >than anything else on the system, you may as well use the cache.) And >programs that do need cache speed would have a better chance of getting >it (even after a task switch.) > > -Sullivan Segall > K. C. Lee #! rnews