Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!uakari.primate.wisc.edu!gem.mps.ohio-state.edu!apple!oliveb!bbn!bbn.com!slackey
From: slackey@bbn.com (Stan Lackey)
Newsgroups: comp.arch
Subject: Re: Self-modifying code
Message-ID: <46852@bbn.COM>
Date: 12 Oct 89 21:26:48 GMT
References: <1080@mipos3.intel.com> <1989Oct11.013553.3893@esegue.segue.boston.ma.us> <527@eedsp.gatech.edu> <1989Oct12.184824.2465@esegue.segue.boston.ma.us>
Sender: news@bbn.COM
Reply-To: slackey@BBN.COM (Stan Lackey)
Organization: Bolt Beranek and Newman Inc., Cambridge MA
Lines: 24

In article <1989Oct12.184824.2465@esegue.segue.boston.ma.us> johnl@esegue.segue.boston.ma.us (John R. Levine) writes:
>In article <527@eedsp.gatech.edu> aaronb@lagrange (Aaron Birenboim) writes:
>>In article <1989Oct11.013553.3893@esegue.segue.boston.ma.us> I wrote:
>>>even the lowly 8086 can fetch up to 6 bytes ahead of where it is executing
>>>[so if you store into the next instruction it will probably execute the
>>>old version]
>>Is this really true?  There isn't enough dependancy checking in the 8086
>>instruction pipe to detect this type of operation, clear the pipe, and
>>re-fetch the altered instruction, or some such corrective measure.
>
>You bet there isn't.  Why waste all that logic to handle the .000001% of
>programs that would want to store into the next instruction?

All the PDP/11's that do prefetching or instruction caching DO check
for possible writes to the next instruction, and flush/refetch/etc to
make it work, simply because it isn't specified NOT to work.  Even
11mode on the VAXes do this.  Some shortcuts are taken, like just
comparing the 8? low bits of a data write to those of the prefetched
instructions; performance will be hurt a little, but erring on the
conservative side always works.

Why "waste" all that logic?  Because it's better for you in the long
run, if as much as possible of old software works on new hardware.
-Stan