Path: utzoo!attcan!uunet!samsung!usc!apple!portal!cup.portal.com!Sullivan
From: Sullivan@cup.portal.com (sullivan - segall)
Newsgroups: comp.sys.amiga
Subject: Re: Whats wrong with self Modifying Code?
Message-ID: <31749@cup.portal.com>
Date: 15 Jul 90 17:13:13 GMT
References: <6180@helios.ee.lbl.gov> <31727@cup.portal.com>
  <13203@mcdphx.phx.mcd.mot.com>
Distribution: na
Organization: The Portal System (TM)
Lines: 79

>>The 68040 snoops the address bus for writes to cached memory, and updates
>>the cache it is sees any.  (I.e: you shouldn't ever have to flush the 
>>cache on any processor >= 68040.)  
>
>BZZZZZZZZZZZZZZT!   Sorry, but we have some lovely parting gifts...
>
>   That the 68040 snoops anything it sees on the bus is true, the problem is
>that all the blitter (and possibly other DMA in different configurations)
>activity is hidden from the processor (allowing the processor do to other 
>things.)
>
If I am writing self-modifying code, I am hardly going to use the blitter
to make the modifications.  (Unless it is copper code, which doesn't have
a cache anyway.)  

The 68040 will always update the execution cache for its own memory writes.
Now whether or not it will update correctly when another device writes to
memory (ostensibly since the Agnus or Ramsey is always in the way) isn't 
something I would know about.

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.

>   The correct answer is that anytime, and that means ANYTIME, the memory
>is loaded with instructions, the cache needs to be flushed.  This should
>be a system call since the application program usually should know nothing
>about the processor executing its code, with the system call handling the
>individual system requirements.  I tried to find one in my 1.2 docs (I
>thought I remembered one), but failed.  For 2.0, I expect "It's in 
>there."  I left enough hints here that I wanted it.

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.  

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.
>
>   More years ago than I care to remember, I had an instructor point out
>that all we had ever written was self modifying code.  Now this instructor
>drilled us through the many courses we had taken that this was a definate
>no no, and I had never stooped so low as to do it, so I was taken aback
>by this statement.  What do you mean, self modifying?  None of our
>programs would have passed!  The point of view he was taking was that
>of the operating system, and that when our program was read into system
>memory, the system's code was modified.  This subtile point was never lost
>on me.  The system, of course, flushed the cache after loading (if so
>equiped.)  You should too.
>
How about some new MEMF_ bits.

	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
_________________________________________________________________
 
/V\  Sullivan  was the first to learn how to jump  without moving.
 '   Is it not proper that the student should surpass the teacher?
To Quote the immortal Socrates: "I drank what?" -Sullivan
_________________________________________________________________
 
Mail to: ...sun!portal!cup.portal.com!Sullivan or
         Sullivan@cup.portal.com
 
>