Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!wugate!uunet!portal!atari!apratt
From: apratt@atari.UUCP (Allan Pratt)
Newsgroups: comp.sys.atari.st
Subject: Re: Self-Modifying Code
Message-ID: <1804@atari.UUCP>
Date: 14 Nov 89 21:13:44 GMT
References: <89316.201227SML108@PSUVM.BITNET> <4301.255ed023@uwovax.uwo.ca>
Organization: Atari Corp., Sunnyvale CA
Lines: 36

7103_2622@uwovax.uwo.ca (Eric Smith) writes:
>In article <89316.201227SML108@PSUVM.BITNET>, SML108@PSUVM.BITNET writes:
>> [...things about self-modifying code...]
>It would have helped if you had included the code that was doing the
>modifications. The 68000 does instruction prefetch.

Yeah, and (as Eric points out) on a TT it will get you in BIG TROUBLE.
Writing to something as data and reading it as code is a BIG NO-NO
unless you invalidate the cache in between.  In fact, on the 68030,
writing something in User mode and reading it in Super mode would
confuse the cache, were it not for a side effect of the write-allocate
bit.

People who do DMA into memory have to worry about that - the BIOS
tries to help, but you can still get in trouble.  Your DMA driver
should execute the following instructions to clobber the cache
after a DMA read and before anybody actually looks at the data:

	movec.l	cacr,d0		; get current cache control register value
	or.w	#$808,d0	; set both "clear" bits
	movec.l	d0,cacr		; write this new value back

The clear bits in the cacr are one-shots, so you don't have to clear
them again.  The code above is harmless if the cache isn't enabled in
the first place, as it doesn't change the enable or other state bits.

The TT is going to open a whole new can of worms, people.  We've been
dealing with it internally, of course, and TOS runs fine, but there are
things which you could get away with on the ST which you can't do on
the TT.  For example, some programs use the high byte of a pointer for
something; with a 24-bit address bus, that's harmless.  But with a full
32-bit bus, that gets you in trouble.

============================================
Opinions expressed above do not necessarily	-- Allan Pratt, Atari Corp.
reflect those of Atari Corp. or anyone else.	  ...ames!atari!apratt