Path: utzoo!utgpu!watmath!ria!uwovax!7103_2622
From: 7103_2622@uwovax.uwo.ca (Eric Smith)
Newsgroups: comp.sys.atari.st
Subject: Re: Self-Modifying Code
Message-ID: <4301.255ed023@uwovax.uwo.ca>
Date: 13 Nov 89 19:30:58 GMT
References: <89316.201227SML108@PSUVM.BITNET>
Lines: 29

In article <89316.201227SML108@PSUVM.BITNET>, SML108@PSUVM.BITNET writes:
> Hi, I am writing an assembly language routine which modifies its own code in
> a tight loop in order to avoid having to do a decision statement at every
> iteration.  Unfortunately, whatever code I am inserting is screwing things up
> royally, and although I have checked it fairly throughly, I cannot figure out
> what is going on.  Question:  Is there something screwy about executable and
> object files that would disallow self modifying.  The block that gets modified
> 
> is this:
> 
>          lsr.w   d3
>          bne     cont
>          add.l   #8,a0
>          move.w  #$8000,d3
>   cont:  nop
It would have helped if you had included the code that was doing the
modifications. The 68000 does instruction prefetch. If you're modifying
code that's really close to the instruction that does the modification,
then you can lose (the chip is executing the instruction it prefetched,
rather than the updated instruction in memory). You can get around this
by sticking some nops in. A better solution is to eliminate the self
modification entirely. I *strongly* suggest the latter, because your code will
almost certainly break on the TT (which has a 256 byte instruction cache).
--
Eric R. Smith                     email:
Dept. of Mathematics            ERSMITH@uwovax.uwo.ca
University of Western Ontario   ERSMITH@uwovax.bitnet
London, Ont. Canada N6A 5B7
ph: (519) 661-3638